[whatwg] Wish for HTMLFormElement.checkValidity(boolean)
So I had to go back into the list archives in 2011/2012 to see the reasons for current behavior. Scripting has no way of trigger full UI validation. Calling form.submit() submits without validation; calling form.checkValidity() will highlight an error but not do any messages. The reason stated was [1]: The theory is that if you are not letting the user agent submit the form, you probably also want to display the validation UI manually. You can easily do that by using the validationMessage attribute on all the elements in the form.elements list. I don't think that theory is correct. When I looked around, there are too many internet questions asking how to trigger full UI validation with scripting. People are looking for this solution (including myself). Today, the only full solution is to completely take over validation and display messages manually to mimic the browser's default behavior. That's not really appealing. I am disappointed that I have to reinvent the wheel (UI wise) simply because I want to customize form submission behavior. One possible solution was to introduce a boolean flag to control when messages show up [2]. That sounds like a much needed solution. What are your thoughts on introducing this method? [1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/0255.html [2] http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Sep/0301.html Cheers, Paul
Re: [whatwg] Wish for HTMLFormElement.checkValidity(boolean)
You may be interested in form.reportValidity().
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
On Thursday 2014-11-06 12:36 -0800, Daniel Holbert wrote: Should these coordinates be relative to... (A) ...the top-left corner of the img element itself? OR (B) ...the top-left corner of the rectangle where the image's pixel data actually maps to? (which may be inside or outside the bounds of the img element) (Of course, parts outside the img won't render and shouldn't receive clicks, but the rect is still there.) I tend to think B is the correct answer, but I'm not 100% sure, and I'd like a sanity-check. I also think it should be (B), since the meaning of the coordinates in the imagemap shouldn't change as a result of CSS styling of the image. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
On Fri, Nov 7, 2014 at 6:35 PM, L. David Baron dba...@dbaron.org wrote: I also think it should be (B), since the meaning of the coordinates in the imagemap shouldn't change as a result of CSS styling of the image. Note that as Daniel pointed out it for legacy reasons already does. img height/width and CSS height/width are the same. Not perpetuating that further makes sense though. -- https://annevankesteren.nl/
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
On 11/07/2014 09:35 AM, L. David Baron wrote: On Thursday 2014-11-06 12:36 -0800, Daniel Holbert wrote: Should these coordinates be relative to... (A) ...the top-left corner of the img element itself? OR (B) ...the top-left corner of the rectangle where the image's pixel data actually maps to? (which may be inside or outside the bounds of the img element) (Of course, parts outside the img won't render and shouldn't receive clicks, but the rect is still there.) I also think it should be (B), since the meaning of the coordinates in the imagemap shouldn't change as a result of CSS styling of the image. I'm not sure I'd quite go that far (RE the meaning of coordinates in the imagemap shouldn't change as a result of CSS styling). I agree in an ideal world, but I don't think we can realistically honor that requirement -- and after thinking about it a bit more, I think I've shifted my opinion to favor (A). :) Stepping back a bit -- I guess there are really two separate questions here: (1) What should be the origin of the image-map pixels? (the upper-left of the img, or the upper-left of the displayed image data?) (2) How big should an image-map pixel be? (Should it be 1px in the img coordinate space (i.e. as wide as 1px of img-width), or should it be in terms of the image's intrinsic-sizing coordinate-space?) (I originally was just asking the first question, but it's probably more sensible to consider both questions together, to fully define the coordinate space.) Focusing on question (2) for the moment: it seems to me that the spec already forces the answer on this question to be use the img's CSS pixel sizing, given the historical note about width height. For example: given an 8px-by-8px square image, which is scaled up to 200px-by-100px using width and height properties, the spec *already* requires that the imagemap coordinates for the center of the image must be (100px,50px) -- not (4px,4px). So, this means the image-map pixels have to be sized according to the img element's CSS-pixel coordinate-space. I can't see a way to use any other pixel-sizing behavior while still preserving this result. So, given that the answer to question (2) is forced to be use the img's CSS pixel sizing, I think my feelings on question (1) are shifting to match that -- it seems like we should be consistent use the img's coordinate-space for that, too. (So, I'm now favoring option (A) from my original email here.) This has the benefit of making image-map coordinates reasonably easy to predict reason about, in display-space, at least. If we could redesign imagemap from scratch, I think it'd be ideal to let specific coordinates reliably map to specific places on the image, regardless of what CSS is applied to the image. But that's already broken by the width/height historical requirement, as noted above; and given that, I think the simplest thing is to just use the img's content-box coordinate-space.
Re: [whatwg] New approach to activities/intents
On 2014-11-03 17:42, Anne van Kesteren wrote: https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very minimal Sharing API could look like. I have often pondered the same when seeing a Share button or icon on a webpage. Some solutions have a single icon that pops up a menu, while other sites has a row of the most common social sites. In retrospect however I realize that any Share API would be no different than how people currently share or bookmark things. A worthy goal would be to help developers de-clutter websites from all those share icons we see today, so if this could be steered towards that it would be great. There are two ways to do this that I'd recommend. A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. Then browser devs can simply utilize that info in their own Share UI (which presumably is tied into the accounts set up on the device/machine in some way). A browser UI could provide a nice looking and device friendly way to add/edit/remove social services that have sharing capabilities (Google+, Facebook, Twitter, Skype, etc.) If the share link is missing this does not mean the page can not be shared, in that case it should be treated as a page is normally treated today, the share link is just a browser hint as to the ideal link to use when sharing this page. Also note that using the link element allows the possibility of using hreflang to present multiple share links (one international aka English and one in the language of the page), or use media to provide multiple share links for different types of devices. There already is a link rel=search so a rel=share just makes sense IMO. It certainly will get rid of the clutter of share icons and buttons on websites (over time), those can be a pain to click on using touch devices (without zooming first), a browser Share UI could easily be hidden on the edge and make se of swipe left from edge or swipe right from edge (or top/bottom etc.) or use gestures to open a Share UI. Some of those share icons may fail to list the social network the user prefer (like email for example) but if that is all setup in the browser then the user can share it at one (or multiple) social services just the way they like it. Also note that title can be applied to such a share link as well, thus providing a suggested title the browser can choose (or not) to use when sharing it. Any icons/logo is either taken from the icon/logo of the current page or from the href linked page (and whatever icon/logo that may have). Existing services like AddThis or ShareThis (two of the more popular ones I believe?) should be able to access the link rel=share params via javascript (to access hreflang and media and title) so they will still remain competitive solutions; I aløso believe there are browser plugins for these two services as well and the browser can/could provide the rel=share link to those types of plugins. Also note that there can be multiple link rel=share and that if allowed when speced that rel=share could be allowed to be global, that way the links to be shared could be inline in the document thus part of the content and useable by the user which is always ideal. Anyway, I'll shut up now before I veer way off topic here. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
On 11/07/2014 09:42 AM, Anne van Kesteren wrote: On Fri, Nov 7, 2014 at 6:35 PM, L. David Baron dba...@dbaron.org wrote: I also think it should be (B), since the meaning of the coordinates in the imagemap shouldn't change as a result of CSS styling of the image. Note that as Daniel pointed out it for legacy reasons already does. img height/width and CSS height/width are the same. Not perpetuating that further makes sense though. I'm actually not so sure I agree (about not perpetuating that further). The width height legacy requirement basically ends up meaning that imagemap coordinates use the img's content-box as their coordinate space. In a More Perfect World, it'd arguably be more useful for specific imagemap coordinates to reliably to map to specific places in the image data (regardless of height/width), but it seems we've already lost that possibility. So, for now, we just have one useful assumption that we can make about these coordinates: they use the img's content-box as their coordinate space. I don't think we should let object-fit/object-position break that assumption, or else we risk making these coordinates completely incomprehensible / unusable. So, I'm now favoring option (A) from my original email. (See my reply to David for more thoughts on this.) ~Daniel
Re: [whatwg] New approach to activities/intents
Roger Hågensen resca...@emsai.net writes: A link element in the header, maybe call it link rel=share href=http://example.com/article/12345/; / or link rel=share / if the current url (or the canonical url link if present) should be used, although I guess in a way rel=share will probably replace the need to use rel=canonical in the long run. I do not understand. Why should one invent a rel value (“share”) that conveys the same semantics as an already existing one (“canonical”) ? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
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
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
