This repository has been archived by the owner on Aug 26, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 114
feat: Nokogumbo detects Nokogiri's HTML5 API #171
Merged
flavorjones
merged 2 commits into
master
from
flavorjones-check-for-html5-already-defined
Mar 17, 2021
Merged
feat: Nokogumbo detects Nokogiri's HTML5 API #171
flavorjones
merged 2 commits into
master
from
flavorjones-check-for-html5-already-defined
Mar 17, 2021
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rubys
reviewed
Mar 14, 2021
rubys
approved these changes
Mar 14, 2021
flavorjones
force-pushed
the
flavorjones-check-for-html5-already-defined
branch
from
March 15, 2021 11:53
457152f
to
5c3ef1e
Compare
Closes #170 A future version of Nokogiri will provide Nokogumbo's API (see sparklemotion/nokogiri#2204). This change will allow Nokogumbo to detect whether Nokogiri provides the HTML5 API and whether to use Nokogiri's implementation or Nokogumbo's implementation. Some contractual assumptions I'm making about Nokogiri: - Nokogiri will faithfully reproduce the `::Nokogiri::HTML5` singleton method, module, and namespace (including classes `Nokogiri::HTML5::Node`, `Nokogiri::HTML5::Document`, and `Nokogiri::HTML5::DocumentFragment`) - Nokogiri will not provide a `::Nokogumbo` module/namespace, but will provide a similar `::Nokogiri::Gumbo` module which will provide the same public API as `::Nokogumbo`. This change checks for the existence of `Nokogiri::HTML5`, `Nokogiri::Gumbo`, and an expected singleton method on each. We could do a more- or less-thorough check here. This change also provides an "escape hatch" using an environment variable `NOKOGUMBO_IGNORE_NOKOGIRI_HTML5` which can be set to force Nokogumbo to use its own implementation. This escape hatch might be unnecessary, but this change is invasive enough to make me want to be cautious. Nokogumbo will emit a single warning message at `require`-time when it is uses Nokogiri's implementation. This message points users to sparklemotion/nokogiri#2205 which will explain what's going on and help people migrate their applications (but is an empty placeholder right now).
flavorjones
force-pushed
the
flavorjones-check-for-html5-already-defined
branch
from
March 15, 2021 13:00
a691655
to
dc68896
Compare
stevecheckoway
approved these changes
Mar 17, 2021
Merged
33 tasks
flavorjones
added a commit
to sparklemotion/nokogiri
that referenced
this pull request
Apr 22, 2021
See rubys/nokogumbo#171 which introduced forward-looking behavior to integrate with a future Nokogiri::HTML5 after the Nokogumbo merger. These tests, which are failing right now, will drive much of the rest of the integration work.
10 tasks
flavorjones
added a commit
to sparklemotion/nokogiri
that referenced
this pull request
Apr 22, 2021
See rubys/nokogumbo#171 which introduced forward-looking behavior to integrate with a future Nokogiri::HTML5 after the Nokogumbo merger. These tests, which are failing right now, will drive much of the rest of the integration work.
flavorjones
added a commit
to sparklemotion/nokogiri
that referenced
this pull request
Apr 26, 2021
See rubys/nokogumbo#171 which introduced forward-looking behavior to integrate with a future Nokogiri::HTML5 after the Nokogumbo merger. These tests, which are failing right now, will drive much of the rest of the integration work.
flavorjones
added a commit
to sparklemotion/nokogiri
that referenced
this pull request
Apr 28, 2021
See rubys/nokogumbo#171 which introduced forward-looking behavior to integrate with a future Nokogiri::HTML5 after the Nokogumbo merger. These tests, which are failing right now, will drive much of the rest of the integration work.
flavorjones
added a commit
to sparklemotion/nokogiri
that referenced
this pull request
Apr 29, 2021
See rubys/nokogumbo#171 which introduced forward-looking behavior to integrate with a future Nokogiri::HTML5 after the Nokogumbo merger. These tests, which are failing right now, will drive much of the rest of the integration work.
23 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What are you trying to accomplish?
A future version of Nokogiri will provide Nokogumbo's API (see
sparklemotion/nokogiri#2204). This change
will allow Nokogumbo to detect whether Nokogiri provides the HTML5 API
and whether to use Nokogiri's implementation or Nokogumbo's
implementation.
This was discussed in-depth at #170.
What approach did you choose and why?
Some contractual assumptions I'm making about Nokogiri:
Nokogiri will faithfully reproduce the
::Nokogiri::HTML5
singletonmethod, module, and namespace (including classes
Nokogiri::HTML5::Node
,Nokogiri::HTML5::Document
, andNokogiri::HTML5::DocumentFragment
)Nokogiri will not provide a
::Nokogumbo
module/namespace, but willprovide a similar
::Nokogiri::Gumbo
module which will provide thesame public API as
::Nokogumbo
.This change checks for the existence of
Nokogiri::HTML5
,Nokogiri::Gumbo
, and an expected singleton method on each. We coulddo a more- or less-thorough check here.
This change also provides an "escape hatch" using an environment
variable
NOKOGUMBO_IGNORE_NOKOGIRI_HTML5
which can be set to forceNokogumbo to use its own implementation. This escape hatch might be
unnecessary, but this change is invasive enough to make me want to be
cautious.
Nokogumbo will emit a single warning message at
require
-time when itis uses Nokogiri's implementation. This message points users to
sparklemotion/nokogiri#2205 which will
explain what's going on and help people migrate their
applications (but is an empty placeholder right now).
What should reviewers focus on?
Please check my assumptions and provide feedback on the decisions made.