Re: [whatwg] script content restrictions vis-a-vis HTML template data blocks
Have you considered using the template element? Thanks for the suggestion. Right now I'm just concerned with the mechanics of script data blocks. These are all conforming; don't forget that the empty string is a string so outer matches the empty string. Ah, ok, thanks, I didn't realize that. I interpreted any string to mean any non-empty string. I suggest that it would be helpful to clarify that. I think it'd be good to modify that note at the beginning of section 4.12.1.2 to make it clear that it's not generally necessary to escape !-- in script data blocks containing HTML / XML -- so long as !-- occurs in sequences matching the comments syntax (12.1.6). Mention template and / or HTML Imports as well if you wish. Thanks, Jesse - Original Message - From: Ian Hickson i...@hixie.ch To: Jesse McCarthy whatwg-2010...@jessemccarthy.net Cc: wha...@whatwg.org Sent: Friday, November 07, 2014 2:55 PM Subject: Re: [whatwg] script content restrictions vis-a-vis HTML template data blocks On Wed, 5 Nov 2014, Jesse McCarthy wrote: Re: the Restrictions for contents of script elements (4.12.1.2): Consider script elements containing data blocks. It's useful to embed templates in these; HTML templates for example. When embedding HTML templates, it would be onerous to have to either omit comments or implement an escaping / unescaping regimen. Have you considered using the template element? The following examples illustrate my interpretation of the requirements for script content. Is this correct? Non-conforming (does not match the outer production before comment-open / after comment-close / or both): script type=text/plain!-- a --/script script type=text/plain !-- a --/script script type=text/plain!-- a -- /script These are all conforming; don't forget that the empty string is a string so outer matches the empty string. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] script content restrictions vis-a-vis HTML template data blocks
Also, look up HTML imports using LINK element. Works well with scoped stylesheets. Thanks for the suggestion. Right now I'm just concerned with the mechanics of script data blocks, but like template, HTML imports is also a useful tool. Thanks, Jesse - Original Message - From: Garrett Smith dhtmlkitc...@gmail.com To: Ian Hickson i...@hixie.ch Cc: Jesse McCarthy whatwg-2010...@jessemccarthy.net; wha...@whatwg.org Sent: Friday, November 07, 2014 3:52 PM Subject: Re: [whatwg] script content restrictions vis-a-vis HTML template data blocks On 11/7/14, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Nov 2014, Jesse McCarthy wrote: Re: the Restrictions for contents of script elements (4.12.1.2): Consider script elements containing data blocks. It's useful to embed templates in these; HTML templates for example. When embedding HTML templates, it would be onerous to have to either omit comments or implement an escaping / unescaping regimen. Have you considered using the template element? Also, look up HTML imports using LINK element. Works well with scoped stylesheets. -- Garrett @xkit ChordCycles.com garretts.github.io
[whatwg] script content restrictions vis-a-vis HTML template data blocks
Re: the Restrictions for contents of script elements (4.12.1.2): Consider script elements containing data blocks. It's useful to embed templates in these; HTML templates for example. When embedding HTML templates, it would be onerous to have to either omit comments or implement an escaping / unescaping regimen. The specification suggests 'to always escape !-- as \!--', which isn't too bad for JavaScript, but would be a hassle for HTML templates. The following examples illustrate my interpretation of the requirements for script content. Is this correct? Non-conforming (does not match the outer production before comment-open / after comment-close / or both): script type=text/plain!-- a --/script script type=text/plain !-- a --/script script type=text/plain!-- a -- /script Conforming (newline characters satisfy the outer production in both positions): script type=text/plain !-- a -- /script Conforming (space characters satisfy the outer production in both positions): script type=text/plain !-- a -- /script
Re: [whatwg] Improve select required
On Monday 13 Sep 2010 Mounir Lamouri wrote: 2. Introduce a placeholder boolean attribute for option and select elements will suffer from being missing if there are no options selected or selected options all have the placeholder attribute set. I also wonder if that would be more straighforward. I suggested / inquired about that when this was being discussed before, but the discussion petered out and no one said anything about it: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027892.html (See last paragraph.) last solution isn't [backward compatible] (ie. the placeholder text wouldn't be shown). However, a workaround can be found using javascript: In my opinion, something that relies on scripting isn't a viable solution. Solution 3, seems to be the nicest and is consistent with the other part of the specifications (placeholder would be used in input and select). That's not viable now because it's not backward compatible, but if people think that would be the ideal solution in the future, would it feasible to specify and implement the following authoring requirements and user agent behavior? * @placeholder for SELECT (as in your #3) AND * @placeholder as a boolean attribute on OPTION (just as a crutch for backward compatibility) AND * @placeholder on OPTION is only valid when @placeholder is also used on the SELECT (and perhaps only if the OPTION's textContent matches the value of the SELECT's @placeholder attribute?) AND * Although @placeholder on OPTION is valid / tolerated under those circumstances, conforming UAs must ignore those OPTIONs entirely and use the value of @placeholder on the SELECT If that's doable, then implementors could implement the behavior for @placeholder on SELECT now and authors could author documents that use the new mechanism and preserve the status-quo for HTML 4 user agents -- an initial label OPTION. When authors stop caring about HTML 4 UAs, they can just stop including an OPTION with @placeholder. Jesse
Re: [whatwg] Constraint validation feedback (various threads)
On Tue, 10 Aug 2010, Jesse McCarthy wrote: I consider it highly desirable to have some way to differentiate between SELECT values explicitly selected by the user and values that were selected by default and unchanged by the user. I have a note in the spec to add a feature at some point to track what controls have been changed and what haven't, but that doesn't seem to have the need for urgency that Jonas describes required= as having, so I still think we should keep delaying that one until browsers have caught up. Allow me to clarify. What I'm referring to is having @required for SELECT and some way to include a label, so that the user must deliberately select something in order for the form to be submitted. My comment was a response to comments you made (see below) that suggested that @required is not important for SELECTs without @size or @multiple, and that an initial label option, e.g. option value=Choose One/option, is invalid. Not having @required for SELECT and simply omitting an initial label OPTION would make the first OPTION (whatever it is) selected by default, which would make it impossible to differentiate between the user deliberately selecting that OPTION and simply leaving the default. Having @required for SELECT and some way to specify a label (as you've just described), so that the user must deliberately select something in order for the SELECT to not suffer from being missing, satisfies the need I described. Regarding how to implement @required a label for SELECTs, some people have resisted the idea of implementing it so that empty string would make it suffer from being missing. Tab Atkins Jr. said this in response: Yes? And when that's valid, you should just *not use @required*, same as when an empty string is a valid value for an input type=text. I've been wondering if someone can present a use case where that logic is not sufficient. I haven't thought of any yet, but I'm not sure there aren't any. Since these specifications have a huge impact on developers for years to come, it's probably better to be on the safe side and just provide some explicit way of marking up a label, such as the means you described. Is the logic that an OPTION is special if it's first and has value= preferable to using an attribute to indicate that? E.g. option dummyLabel/option (not suggesting that as an actual attribute name, just using it for illustration). Or perhaps @placeholder could be a boolean attribute on OPTION? Jesse On Mon, 9 Aug 2010 Ian Hickson wrote: It's impossible to submit a select element (without a size= attribute or multiple= attribute) without it having a value -- essentially, required= is already implied. On Thu, 22 Jul 2010, Mounir Lamouri wrote: 1. A typical use case of select is to have option value=''Choose an option/option as a default value. Having @required would prevent authors to write any js check when they are using select like that. That seems like an invalid use of option to me. It would be better as: label Choose an option: select ... /select /label Currently you can do this just by not providing empty values and not using multiple= or size=. - Original Message - From: Ian Hickson i...@hixie.ch To: wha...@whatwg.org Sent: Wednesday, August 11, 2010 6:03 PM Subject: Constraint validation feedback (various threads) On Tue, 20 Jul 2010, Mounir Lamouri wrote: At the moment, three form elements are barred from constraint validation: object, fieldset and output. I can understand why object and fieldset are barred from constraint validation but I think output could use the constraint validation. The user can't edit the value of output, so the only time this would be helpful is when you have script, with the script setting the validity using setCustomValidity(). But then the script can just as easily set it on the control that's actually making the output be invalid. That would also be better UI -- having the user agent point out the output control is invalid would likely just infuriate users who couldn't tell what they had to do to change the value. On Tue, 20 Jul 2010, Mounir Lamouri wrote: I'm wondering why there is no categories for elements candidate for constraint validation. In the current state of the specs, all listed elements are candidate for constraint validation except when they are barred from constraint validation. Barring an element from constraint validation when it is in a certain state seems good but having elements always barred from constraint validation seems a bad idea. It makes them having the entire constraint validation API for nothing. Not quite nothing -- they have it so that you can iterate through form.elements and use the constraint validation API on all of them. On Tue, 20 Jul 2010, Simon Pieters wrote: I believe some elements have the API but are barred because it makes it easier to loop through form.elements and do the validation stuff
Re: [whatwg] select element should have a required attribute
I'm not sure what the right solution is, but here's my two cents. I consider it highly desirable to have some way to differentiate between SELECT values explicitly selected by the user and values that were selected by default and unchanged by the user. For that reason I've commonly included Choose one options: option value=Choose one/option I can think of lots of places where an empty string is in-fact very useful for a select element, such as filters on search results forms I also see Ashley's point because I've done that too. E.g. select name=gender option value=Doesn't matter/option option value=MMale/option option value=FFemale/option /select However, I think in those cases I could substitute some other value for empty string (e.g. * in this case) that would communicate the necessary information to the server-side logic. If you need to do that, then maybe use radio buttons instead. I don't see that as a practical alternative in many cases: radio buttons take up a lot more space. Even in the gender example I gave, using radio buttons instead would have a detrimental effect on the layout of the particular form I took the example from. And when there are more options it makes a huge difference. Radio buttons could be very unwieldy where a SELECT works well. Jesse - Original Message - Date: Tue, 10 Aug 2010 10:35:53 +0100 From: Ashley Sheridan a...@ashleysheridan.co.uk If you receive an empty text box then a required element works to validate against empty input. As you produce the input for the select list, it's pretty stupid to say that it shouldn't have an empty string for a value because you put it there. I can think of lots of places where an empty string is in-fact very useful for a select element, such as filters on search results forms, but if there's any places that I want a value, then I don't leave empty elements lying around. If you need to do that, then maybe use radio buttons instead. Thanks, Ash http://www.ashleysheridan.co.uk
[whatwg] Headings and sections, role of H2-H6
I think the new section and heading model in HTML 5 is a welcome development. I've actually essentially been doing it that way for years -- eschewing H2-H6 and using DIV as a stand in for SECTION. I've always considered the H1-H6 concept a mess, and thankfully that seems to have been recognized by the people working on this spec. My understanding is that in HTML 5 the following is acceptable, and at least as acceptable as the alternative: use just H1, in conjunction with SECTION; forego use of H2-H6 for the most part; and, allow heading level to be determined by section nesting level. Is that correct? My question is about the explanation and code sample in the HTML 5 Working Draft section [4.4.11 Headings and sections]: Sections may contain headings of any rank, but authors are strongly encouraged to either use only h1 elements, or to use elements of the appropriate rank for the section's nesting level There are 2 code examples shortly after that passage, and the following one is indicated as being preferable to the other one because the sections are explicitly marked up instead of implied: body h1Apples/h1 pApples are fruit./p section h2Taste/h2 pThey taste lovely./p section h3Sweet/h3 pRed apples are sweeter than green ones./p /section /section section h2Color/h2 pApples come in various colors./p /section /body My point is that the passage makes it seem like using H1 throughout vs. using elements of the appropriate rank for the section's nesting level are equally sound and encouraged, and the code sample uses H2 and H3. I see why H2-H6 are retained for certain uses, but -- except in an HGROUP -- there's no good reason to use H2-H6 when writing new code with explicitly marked-up sections, is there? In that scenario isn't using just H1 throughout decidedly preferable to using H2-H6? And if so, then as long as authors are being strongly encouraged to mark up headings a certain way, wouldn't it be ideal to state a clear preference for using H1 throughout and include a third code example, indicated as the ideal: body h1Apples/h1 pApples are fruit./p section h1Taste/h1 pThey taste lovely./p section h1Sweet/h1 pRed apples are sweeter than green ones./p /section /section section h1Color/h1 pApples come in various colors./p /section /body
