| 07:53 | <annevk> | Hmm, navigator.userActivation is somehow specified in a completely different way from all other navigator members. |
| 11:20 | <csarven> | Does/Can the type attribute on the pre element (similar to https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type ) help express the type of the formatted text? |
| 11:33 | <annevk> | csarven: https://html.spec.whatwg.org/multipage/grouping-content.html#the-pre-element suggests using nested elements. (And I think there's a further suggestion to use the class attribute on code to denote a programming language.) |
| 13:11 | <csarven> | Thanks @annevk . I have noted the use of the class attribute before but AFAIK, language- is not a prefix for a prefined language as suffix.Would <pre type= violate anything and/or not particularly meaningful for processing software? Its use would be similar to <script type= in that it indicates content corresponds to a MIME type. A class value is relatively arbitrary compared to type using a MIME type. |
| 13:26 | <annevk> | csarven: since it's not a defined attribute for the pre element it would be non-conforming HTML and might clash with future extensions of HTML. Not recommended. |
| 13:27 | <annevk> | csarven: also note that for script we have explicitly moved away from using MIME types for the type attribute. |
| 14:27 | <csarven> | Nod "moved away from" but as I understand it, conforming values are not limiited to MIME types so far as that data blocks are still allowed in the context of script.Is there a definition or advisement on using or error handling attributes that are not defined by a particular element? There are a couple of points in https://html.spec.whatwg.org/multipage/introduction.html#syntax-errors and https://html.spec.whatwg.org/multipage/introduction.html#restrictions-on-content-models-and-on-attribute-values but nothing specifically jumps out. I ask because if use in the wild is one way for standardised adoption, how can authors know whether they can use something without violating the specification. I'm not trying to insist <pre type (although it makes sense to me) but trying to better understand the process. Thanks. |
| 14:50 | <zcorpan> | csarven: a quick check is running your doc through https://validator.nu/ / https://validator.w3.org/nu/ |
| 14:51 | <zcorpan> | csarven: less quick is to read the HTML standard and follow the conformance criteria that apply for documents |
| 14:52 | <zcorpan> | csarven: in this case https://html.spec.whatwg.org/multipage/grouping-content.html#the-pre-element says Content attributes: Global attributes which does not include type |
| 14:54 | <zcorpan> | csarven: for user agents the requirement is to follow the defined processing per spec, regardless of what is allowed or not allowed for documents |
| 16:13 | <Adıl Babayev> | Salam |
| 16:40 | <csarven> | @zcorpan I have read the relevant parts of the spec but like I said what the intended error handling is not clear to me. I understand what the validator says and can observe what browsers do but that's it. Is there a processing instruction that says "when a processor encounter an unrecognised attribute, it must/advised to...". I understand it is 'non-conforming' on paper with respect to the spec. That aside, any particular reason one should not propose having the type attribute on the pre element? If UAs are to follow the spec, then how do you get something into the spec? Just make the proposal? Show usage in the wild to support the proposal? |
| 16:58 | <Luke Warlow> | Got a question that I think this is probably the best place to ask. WebKit and Chromium (haven't checked firefox) have this Element::finishParsingChildren() method that gets called from various places. I'm not able to find a corresponding place in the HTML spec for this behaviour though? Does one exist or is there a close aproximate step in the spec anyone knows? I understand it's generally not encouraged to be used but I think I have a legitimate need for it. |
| 17:01 | <annevk> | Luke Warlow: it's when the parser does something for an end tag, such as </script>. And unless there's a legacy thing, I really think we shouldn't be adding more of it. |
| 17:03 | <Luke Warlow> | I need some hook to know when a script finishes parsing to know to set an internal slot. Though there's added complexity because you can change the contents mid-parse and that shouldn't be set to the slot. So maybe that shows there should be some other approach. |
| 17:21 | <zcorpan> | csarven: If the spec doesn't say to do something, UAs aren't expected to do something. i.e. ignore unknown attributes. Other specs can define some processing however. |
| 17:22 | <zcorpan> | csarven: for the second question, see https://whatwg.org/faq#adding-new-features |
| 18:02 | <annevk> | Luke Warlow: for script it's no problem as it's already magic (if you search for "script" inclusive of quotes you'll find where it's handled) |