Remaining issue: custom attributes inside custom elements still been colored as unknown attribute,
They are used by WHATWG spec, HTML it self, but I seems can't find the definition in the spec.
This appears to me to be lessening the usefulness of the lexer: if the user currently wants "my-checkbox" to be a known-good custom element in their work then they can add it to hypertext.elements. With this change, all custom elements are treated as known so there will be no highlighting of unwanted or incorrectly spelled custom elements.
Example custom element "my-checkbox":
<formaction="..."method="..."><label><my-checkboxname="agreed"></my-checkbox> I read the agreement.</label><inputtype="submit"></form>
"font-face-format" seems to show >1 "-" allowed. The patches are spreading out the custom element logic making it more difficult to understand - wrap it in a function: starts with lower case and only contains lower case and "-".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The specification defines valid custom element names with They do not contain any ASCII upper alphas, ensuring that the user agent can always treat HTML elements ASCII-case-insensitively.. I interpret this as meaning that the custom element in HTML is case-insensitive and its the definition of the element that is case-sensitive. Thus the onlyLowerCase variable is not needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Shouldn't the IsLowerCase inside isHTMLCustomElement also be removed?
The point of the listed element names "annotation-xml", ... is that they are used by SVG and MathML and thus should be avoided when choosing new custom element names. LexHTML.cxx leaves the choice of valid element names up to the application which can set up keywords for the particular version/view of HTML it wants. If it wants to allow MathML then it includes "annotation-xml" in the set of keywords alongside "annotation". Thus, reservedCustomElementTagNames isn't needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why is the IsLowerCase required? There is a difference here between the name of the custom element and references to that name in HTML documents. Reemphasising:
user agent can always treat HTML elements ASCII-case-insensitively
The image is showing that "My-CheckBox" with an initial upper-case is seen as valid by the inspector so I don't understand the point you are making with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Patch for highlight custom elements.
scite-html-microdata.diff added microdata attributes to SciTE,
https://html.spec.whatwg.org/multipage/microdata.html#microdata
Added empty checking.
Simplified the constructor.
Remaining issue: custom attributes inside custom elements still been colored as unknown attribute,
They are used by WHATWG spec, HTML it self, but I seems can't find the definition in the spec.
This appears to me to be lessening the usefulness of the lexer: if the user currently wants "my-checkbox" to be a known-good custom element in their work then they can add it to hypertext.elements. With this change, all custom elements are treated as known so there will be no highlighting of unwanted or incorrectly spelled custom elements.
Example custom element "my-checkbox":
"font-face-format" seems to show >1 "-" allowed. The patches are spreading out the custom element logic making it more difficult to understand - wrap it in a function: starts with lower case and only contains lower case and "-".
Cleaned the patch. SciTE added the
isattribute.Committed the changes to SciTE properties files as [4e603a] and [fe063d].
Related
Commit: [4e603a]
Commit: [fe063d]
The specification defines valid custom element names with
They do not contain any ASCII upper alphas, ensuring that the user agent can always treat HTML elements ASCII-case-insensitively.. I interpret this as meaning that the custom element in HTML is case-insensitive and its the definition of the element that is case-sensitive. Thus theonlyLowerCasevariable is not needed.Rename onlyLowerCase to hasUpperCase (direct edit the patch).
The EBNF don't include upper case alphas.
Fix the patch.
Removed ASCII case checking.
Screenshot is test following with Firefox and Chrome (all tag and attribute names been normalized to lower case):
Shouldn't the IsLowerCase inside isHTMLCustomElement also be removed?
The point of the listed element names "annotation-xml", ... is that they are used by SVG and MathML and thus should be avoided when choosing new custom element names. LexHTML.cxx leaves the choice of valid element names up to the application which can set up keywords for the particular version/view of HTML it wants. If it wants to allow MathML then it includes "annotation-xml" in the set of keywords alongside "annotation". Thus, reservedCustomElementTagNames isn't needed.
The IsLowerCase is required. Maybe other checks for validating following also required:
"-" | "." | [0-9] | "_" | [a-z]Why is the IsLowerCase required? There is a difference here between the name of the custom element and references to that name in HTML documents. Reemphasising:
The image is showing that "My-CheckBox" with an initial upper-case is seen as valid by the inspector so I don't understand the point you are making with it.
Fortunately, extra validating is not needed.
Updated patch replace tag.empty() with tag.length() < 2.
It's likely,
]is missing from setTagContinue (because only[is present). This change is not included in the patch.Last edit: Zufu Liu 2019-07-12
It just check tag[0] is alpha (after MakeLowerCase()), fixed caseSensitive.
Committed as [66cf17] with supporting change [89efa5] due to same code area being changed for [feature-requests:#1320].
Related
Feature Requests:
#1320Commit: [66cf17]
Commit: [89efa5]
Committed case sensitivity fix as [11b480] .
Related
Commit: [11b480]