[whatwg] Responsive image maps
Hi everybody. I know that my idea can be seen as weird but I prefer to try and receive negative answers, than remaining with nothing. Today embedding images in a page is more complex than before and it allows responsive pictures, too. But there's a feature associated with images and, though still existing (I hope it isn't only for legacy reasons), it has remained quite archaic. I'm referring to map client-side image maps. I guess that implementation of map is not wide enough (at all?), but in the age of responsive design and varying screen sizes, they will be soon extinct because a fixed image map is simply useless. Now, I don't want to discuss rendering issues (it's not true. I wish I could), but rather another simple question: why can't map area coordinates be responsive? I know that percentages simply don't work as UAs either interpret them as pixel, or they aren't interpreted at all. But what about rescaling? Imagine something like this (it's a simple example with also an idea for legacy compatibility): map id=mapname name=mapname sizes=400x300 area type=circle coords=50,60,40 / area type=rect coords=0,200,400,300 / /map The @sizes attribute indicates the base dimensions for map rescaling. Lacking it, the map is not resized (so to preserve legacy maps. Polyfill resizing scripts could detect UAs which implement it and let them do it automatically). When the map is applied to an image, 2 values horizontal_ratio (CSS-img-width / map-width) and vertical_ratio (CSS-img-height / map-height) are calculated (I guess they should be 2 because CSS can be improperly used to stretch the image). Then coordinates can then be adjusted according to proper (hor/ver) ratio. (of course in case of stretching circles should be turned into ellipses where major_axis= 2 * radius * horizontal_ratio, minor_axis = 2 * radius * vertical_ratio, I don't think such a transformation is difficult for modern UAs). Image maps are a powerful tool that allows to define active regions in an image. The huge difference from old server-side maps is that map is active on the user agent, and as such it allows more inter-activity. It's way easier than specifying something similar in canvas elements, IMO, and it is native technology (authors have resorted to use Flash stuff because it had better rendering without any real improvement for interactivity). But authors prefer relying on layer overlapping. Which is sad because it makes basically the same as area type=rect, in a custom way. Every time I see something like that, I compare it to 2-column pages made with tables. I know that a major objection could be that map elements have been out of favor even before responsive design became a focus, but I think it depends on the lack of any relationshipt between maps and rendering layer. Is there any chance that such tool is improved?
Re: [whatwg] Responsive image maps
That's exactly what I had in mind. I worked for a similar solution (now sadly aborted). It implemented a world map with selectable countries instead of free text fields / dropdown list. I had to use Flash because image maps cannot be resized. I like the idea of using both width and height for consistency, but I am worried about what could happen when either attribute is specified. Of course it would be equally needed to state what is the meaning of a sizes attribute without separator (it could mean that the base map is to be intended as a square, maybe). I took the idea of x meaning times from the current spec about @srcset, where #x refers to CSS pixel density. And as an evidence that someone needs this feature, I could cite several resizing scripts, both standalone https://github.com/davidjbradshaw/image-map-resizer http://stackoverflow.com/a/14576104 and jQuery-based https://github.com/stowball/jQuery-rwdImageMaps 2015-03-18 16:50 GMT+01:00 Martin Janecke whatwg@prlbr.com: Am .03.2015, 12:38 Uhr, schrieb Andrea Rendine master.skywalker...@gmail.com: […] why can't map area coordinates be responsive? I know that percentages simply don't work as UAs either interpret them as pixel, or they aren't interpreted at all. But what about rescaling? I'd like to interpret this question as a request and support it. Imagine something like this (it's a simple example with also an idea for legacy compatibility): map id=mapname name=mapname sizes=400x300 area type=circle coords=50,60,40 / area type=rect coords=0,200,400,300 / /map The @sizes attribute indicates the base dimensions for map rescaling. Lacking it, the map is not resized (so to preserve legacy maps. Polyfill resizing scripts could detect UAs which implement it and let them do it automatically). When the map is applied to an image, 2 values horizontal_ratio (CSS-img-width / map-width) and vertical_ratio (CSS-img-height / map-height) are calculated (I guess they should be 2 because CSS can be improperly used to stretch the image). Then coordinates can then be adjusted according to proper (hor/ver) ratio. This sounds like an easy solution. I'd just suggest to consider whether the @sizes attribute could be expressed differently, i.e. without a new syntax like the x for times. For example, the img element uses two attributes @width and @height to express something similar. Following that example might lead to a more consistent result. I know that a major objection could be that map elements have been out of favor even before responsive design became a focus, but I think it depends on the lack of any relationshipt between maps and rendering layer. Image maps are still used even in a responsive environment. Here's an example from the wild: https://www.deutscheskonto.org/en/ The image using the map is https://www.deutscheskonto.org/images/en/deutsches-konto-600-en.jpg This example uses JavaScript to make the map responsive, but doesn't work when the client has JavaScript disabled. While JavaScript could be used to solve the use case, making image maps responsive is such an obvious application that it makes sense to standardize it without JavaScript. It seems to be the natural evolution of image maps in a time of vastly varying screen sizes. Non-responsive image maps get less and less useful, actually. Martin
[whatwg] MetaExtension and Dublin Core revision
More than one year ago I first updated the page MetaExtension on WHATWG wiki, in order to introduce values for @name according to DCMI dc-html documentation (http://dublincore.org/documents/dc-html/). There are several mistakes in the dc. and dcterms. list as of now, I tried to fix them, but my edit was reverted because items cannot be removed that easily. So I will submit my edit request here and wait for approval. Changes to make: - The properties dc.created, dc.date.issued, dc.dateCopyrighted, dc.dateSubmitted, dc.license, dc.mediator, dc.medium, dc.modified, dc.provenance, dc.references, dc.temporal, dc.valid are to be REMOVED because not defined by the specification. dc.prefixed properties can be associated to both /terms/ and /elements/1.1/ Dublin Core property namespaces, and in the table they are associated to the latter. /elements/1.1/ does not define these properties. + The properties dc.contributor, dc.coverage, dc.date, dc.format, dc.identifier, dc.relation, dc.rights, dc.source, dc.subject, are to be INTRODUCED, as defined in /elements/1.1/ namespace. Some of them are now meant to define values in a non-literal range, but the notion of ranges does not apply to /elements/1.1/ namespacce properties and so they should be valid (though for legacy purposes). + all dc.prefixed properties should present a note advising authors NOT to use them when a value in the proper range is to be provided (/elements/1.1/ namespace is maintained for legacy reasons, as some properties could have a value not fitting the range as it was defined in 2008 revision; however, now specific ranges have been defined, so it is auspicable that authors conform to them; in that case the more specific /terms/ namespace properties: http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces). - The property dcterms.collection is to be REMOVED as it defines a class of properties in DCMI specification, not a real property - The properties dcterms.hasFormat, dcterms.hasPart, dcterms.hasVersion, dcterms.isFormatOf, dcterms.isPartOf, dcterms.isReferencedBy, dcterms.isReplacedBy, dcterms.isRequiredBy, dcterms.isVersionOf, dcterms.references, dcterms.relation, dcterms.replaces, dcterms.requires, dcterms.source, dcterms.subject are to be REMOVED, because per spec these properties are meant to define non-literal values and as such meta@name is not suitable. These properties are ONLY to be defined with link@rel elements ( http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms). + Properties whose value can reasonably be either a literal or a non-literal surrogate should be marked with a note stating that, if a resource non-literal reference is to be provided, it is better to use a link rel=dcterms.property href=reference title=literal definition / rather a meta element whose content is a string. These properties are those defined in the http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions list with a proper synonim field is present. Note, however, that this selection, differently from the previous one, is personal and based on common sense (a value in the Agent class can be defined either as a name or as a reference to a personal profile, but a date is basically a string and there's no reason to express it as a reference, even if ranges are respected). + Prefix structures, both in namespace definition link rel=schema.DCTERMS/DC and in properties meta name=DCTERMS/DC should be capitalised both in existing properties and in those defined in this message (I wrote them lowercase for the sake of uniformity). Please allow these changes in order to align the table to DCMI spec. Thanks in advance.
Re: [whatwg] Responsive image maps
SVG can be resized. Everything inside it cannot, as far as it is not defined by relative units. And percentage is not limited to ingegers, of course, but it requires a value conversion. And I'm not sure it works with polygons. 2015-03-20 21:15 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine master.skywalker...@gmail.com wrote: About SVG, I made a couple of tests and they are far from being comprehensive, but this is the fact. SVG image maps need to define 2 elements for each area, i.e. the element itself and its associated hyperlink. That's really not much: svg width=... height=... image src=foo ... / a href=target1polygon points=... //a a href=target2rect ... //a ... /svg The markup complexity seems to be about the same as using img/map/area, especially if you accompany it with prose like the example in https://html.spec.whatwg.org/multipage/embedded-content.html#the-map-element shows. And while SVG graphics offers a wider range of instruments, such a complexity is not always of much use. As such it could be useless to vectorially define parts of the image when the purpose is just to apply a series of shaped links on a preexisting layer-0 image, as it could happen with geographical maps, non-vectorial logos/charts, pre-elaborated graphics. What is important, instead, is that inline SVG images cannot be resized with CSS. And as such they aren't responsive, exactly as image maps. svg elements can be resized by the CSS 'width' and 'height' properties just fine. The only case where CSS resize applies to SVG graphics is when they're used as source for img tag (apart from IE). And in that case hyperlinks are disabled. What we are left with is relative measurement, expressed in percentage for example, but IMHO this is not optimal. On one hand, measuring on base 100 decreases precision, Percentages are not base 100. They're full decimal numbers. You're not limited to integer percentages. ~TJ
Re: [whatwg] MetaExtension and Dublin Core revision
Hi again. I hope anyone takes the time to review my request about MetaExtension and Dublin Core revision. The metadata properties list as it is now on the page is out of its proper specification. Thank you for the help. Andrea Rendine
Re: [whatwg] Responsive image maps
Why are alternatives like CSS-positioned a links or SVG not better?
The issue with CSS is easy. All that can be achieved through it is
rectangles/squares (and their transformations), circles and some
approximation of ellipses (with border-radius). The third feature allowed
by image maps, polygon-shaped areas, cannot be achieved this way.
About SVG, I made a couple of tests and they are far from being
comprehensive, but this is the fact. SVG image maps need to define 2
elements for each area, i.e. the element itself and its associated
hyperlink. And while SVG graphics offers a wider range of instruments, such
a complexity is not always of much use. As such it could be useless to
vectorially define parts of the image when the purpose is just to apply a
series of shaped links on a preexisting layer-0 image, as it could happen
with geographical maps, non-vectorial logos/charts, pre-elaborated
graphics. What is important, instead, is that inline SVG images cannot be
resized with CSS. And as such they aren't responsive, exactly as image
maps. The only case where CSS resize applies to SVG graphics is when
they're used as source for img tag (apart from IE). And in that case
hyperlinks are disabled.
What we are left with is relative measurement, expressed in percentage for
example, but IMHO this is not optimal. On one hand, measuring on base 100
decreases precision, and on the other hand it means defining an SVG
viewport (and related image) 100% x 100% without benefitting of native size
and, what's important, a native ratio, and include it inside an element
whose size is governed by CSS (again, without a native size ratio to rely
on) (didn't test with em units, but the fact is, a simple element{width}
CSS rule wouldn't work). Of course it could be still be of use, but it's
too much of a complexity to force authors on, in easy cases.
Finally, IDK if it can be of any use, but image maps can be defined in
another part of the page itself, so as to provide a list of links added to
the image itself (in some projects it could be useful to leave the user a
choice over favourite interface). Of course this could be done repeating
the links, but it can be avoided.
As a side note, I agree with Martin Janecke. Image maps are still of use
and never gone deprecated. I guess it'd be better to have 2 features which
achieve the same objective in a different way, rather than to force authors
to use SVG just because the other idea hasn't been improved.
2015-03-20 20:30 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com:
On Fri, Mar 20, 2015 at 12:22 PM, Martin Janecke whatwg@prlbr.com
wrote:
However, since image maps have been an integral part of HTML since
version
3.2 and not been deprecated in favor of a better alternative yet, it
might
still be a straightforward solution to enhance them. Responsive image
maps
would be backwards compatible to all non-graphical clients that support
at
least HTML 3.2 such as Lynx, various bots and presumably most screen
readers. Accessibility is already solved for image maps.
What are the accessibility implications of using SVGs? In an image map,
an
area element used as a link must have an @alt attribute providing a
link
text. It seems that an SVG could use the desc element for that purpose,
but it isn't mandatory. Is it understood as link text by screen readers?
In
case it isn't: do screen reader vendors plan to parse SVGs and make
(links
in) them accessible in the future? What about search engines? Do/will
they
handle hyperlinks in SVGs like a and area hyperlinks in HTML?
SVG is highly accessible. Yes, SVG a elements are followed just
like HTML a elements, and yes, screenreaders do read out desc
elements when appropriate.
~TJ
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
As an author I shall offer my 2 cents too. First off, I'm for native implementations and all that markup and CSS can do on _existing_ content. Thus said, I prefer having JS manipulating the content with AJAX than having the markup doing that. Apart from the concept that markup itself is being pushed too far, from an instrument capable of specifying properties for its content to something acting on its own, I think there's more potential for security issues than for genuine manipulation. Maybe things will move towards that end from now on, as websites have to look like web apps and this means that they have to be apps executed on a browser platform, but I personally prefer an ideal model where - html provides static content, i.e. content which does not change when looking at the page structure itself - css provides ALL the graphic/presentational stuff and even some interface, (everyone can imagine what can be done with :target or :checked selectors...) - js provides dynamic content, i.e. whatever is to be considered part of the content itself when actions are executed or events are fired. Let's see what happens, then. This was just an idea. 2015-03-24 13:07 GMT+01:00 Neal Gompa ngomp...@gmail.com: I think I can firmly say that I'm not in the JS all the things camp. I do see the reasoning behind this, but I'd like to point out that not everyone in the world would like to use the MVC model. Personally, I don't mind it (since it offers a logical separation of data, presentation, and operational logic), but I know of those who hate it. Also, I'm a little terrified of having SQL directly in the markup. There's so much potential for that to go horribly wrong. Personally, I feel things that involve data retrieval should be better handled by endpoints that return HTML, XML, or JSON. Putting it in the user-accessible markup is dangerous. Some of these things you're asking the browser to do, I don't think the browser should be doing. Fundamentally, web sites are a client/server model, and we shouldn't heap on too much into the client side. Part of the problem with that is the computational complexity (which is a problem in developing countries where low end devices are the norm). The other part is that you are essentially trusting the user device to be secure, which is a terrible idea no matter how you slice it. The main reason that browsers get so much heaped onto it these days is because we've not really evolved the role of the server in website design. It's been the same for years, which is fine, except that it's clearly not good for the mobile world (as more complex processing moves from the server to client). I don't know the appropriate forum for discussing that particular issue, but I think we need to make the server side of this more intelligent, too. I think it makes sense to extend HTML to support single document website models like this, but I'm extremely wary of mandating the browser to process data directly. An individual developer can make that choice himself/herself, but I'd rather not mandate that workflow. Instead, enabling partial refreshing and using endpoints with URI request information to retrieve the desired portions of the page to load up makes a lot of sense. But we also need this to be a linkable model. I'm not sure how you can make a desired variant of the page linkable from an external source (such as Wikipedia or a news organization site). On Tue, Mar 24, 2015 at 5:18 AM, Bobby Mozumder mozum...@futureclaw.com wrote: https://github.com/mozumder/HTML6 I’ll be updating that Github with more ideas and refinement about the proposal with occasional feedback into this list. Since this is getting some attention it’s probably better to place the ideas in a setting that can be updated/modified than to discuss it informally via email over here. This is still at the concept phase and I’ll be looking at feedback from other people as well as other frameworks to see the good they offered as well as what caused them to fail. In this version, a key change is that I added an MREF property to A elements to separate the canonical URL from an API URL, and a RECEIVER property to specify where the API data loads: A href=“http://www.mywebsite.com/article-2.html; mref=“ http://api.mywebsite.com/article-2; receiver=MyArticleData The MREF will maintain backwards compatibility. You can use the same web page in an older browser and it operates fine, it just won’t load API endpoints, but will reload full page from the HREF. And previously I had a MODEL property in place of RECEIVER, but that's the overall model’s outlet for all elements, not a receiver model, which can be different. Adding a MODEL property would load the model’s properties into the HREF and/or A element. I also changed the fixtures in the example from XML to JSON. I always thought XML was more readable when mixed with HTML, but it
Re: [whatwg] Page refresh interface
Now I tested the interface. Here the results, just for completeness. - IE does have such a command. I had a bad time looking for it, because I'm Italian and the Italian translation is really poor (Consenti aggiornamento metadati, i.e. Allow metadata to be refreshed instead of Allow meta refresh). However, it does not prompt at all whether the specific site you are browsing has a refresh directive. - FF has a better interface, as it prompts the user about the specific site. However, if the Prompt user command is checked, the user is notified only when meta refresh directive is present, and if confirmed the page is refreshed at once, not on timeout. On the other hand, if a refresh header directive has been sent and the command is checked, the interface disappears instantaneously and the refresh is aborted altogether. - Opera (last version) has the same settings interface of Chrome and I didn't succeed in finding the mentioned command. Can't test on Safari (I'm a Win user), but I confirm about Chrome. However the bulk of my issue remains: wouldn't it be useful if there were a refresh property to be accessed for the document? 2015-03-24 10:49 GMT+01:00 Andrea Rendine master.skywalker...@gmail.com: Thank you, I'll have to test on IE and Opera. Does that interface interact with refresh instruction given by the header too? (The answer could also be negative, as the refresh response header has been introduced by Netscape for what I know) 2015-03-24 5:17 GMT+01:00 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net: Andrea Rendine master.skywalker...@gmail.com writes: Besides that, the spec says that UAs may expose the time (and other aspects) for a refresh event of the document and it also refers to the possibility for a user to cancel the redirect, while as of now users aren't even informed, let alone allowed to interact with this event. FYI, Firefox has a “Warn me when web sites try to redirect or reload the page.” option, Internet Explorer has “Allow META REFRESH” and Opera had a similar feature. AFAIK, Chrome and Safari do not have these options. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Page refresh interface
Thank you, I'll have to test on IE and Opera. Does that interface interact with refresh instruction given by the header too? (The answer could also be negative, as the refresh response header has been introduced by Netscape for what I know) 2015-03-24 5:17 GMT+01:00 Nils Dagsson Moskopp n...@dieweltistgarnichtso.net: Andrea Rendine master.skywalker...@gmail.com writes: Besides that, the spec says that UAs may expose the time (and other aspects) for a refresh event of the document and it also refers to the possibility for a user to cancel the redirect, while as of now users aren't even informed, let alone allowed to interact with this event. FYI, Firefox has a “Warn me when web sites try to redirect or reload the page.” option, Internet Explorer has “Allow META REFRESH” and Opera had a similar feature. AFAIK, Chrome and Safari do not have these options. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
[whatwg] Seamless browsing context in object elements
Hi everybody. The title says all, so this time, short request and therefore short message. The specification says that object elements' associated resource can be treated as a nested browsing context. But it can't be specified with iframe new S-attributes (@srcdoc, @sandbox and @seamless). I can understand the reason for @sandbox, as I guess that sandbox limitations could be incompatible with plugins. I can understand why not @sandbox as well (that's good for a very specific context I think). But what about @seamless? Is there a reason why it does not apply to object browsing contexts? Thank you very much for your patience. Andrea Rendine
Re: [whatwg] Responsive image maps
Note that it's perfectly fine to reference svg files from a picture element, see e.g http://sarasoueidan.com/blog/svg-picture/. Which means repeating the map construction for every SVG file. Of course if the SVG is created by a script or a graphics application it can be done easily, but this is not always the case. However, before this discussion about SVG goes too far, and also keeping in mind some limitations of SVG itself (as I said before), I ask again: why not improving an existing feature instead of finding so many expensive workarounds? It'd allow authors the choice to use between 2 different tools for different cases. 2015-03-24 14:36 GMT+01:00 Erik Dahlström e...@opera.com: On Sun, 22 Mar 2015 15:06:40 +0100, Martin Janecke whatwg@prlbr.com wrote: I've done a few tests and provide links to them below the following discussion. ... Test 4: https://prlbr.de/2015/03/inline-svg-without-height.html Test 5: https://prlbr.de/2015/03/inline-svg-without-size.html Test 4 is almost identical to test 3, but I haven't specified a height on the the SVG element this time. Test 5 has neither height nor width specified for the SVG and always gets its size by fitting in the surrounding figure element. Both tests work as expected in FF, Opera, Safari and Chrome. IE9 doesn't get the size right. Test 5 is the proper way to do this IMHO. A workaround for the bug in IE9+ is to add a wrapper element that does the responsive sizing. Something along the lines of http://jsfiddle.net/vo1ofz0w/1/. Test 6: https://prlbr.de/2015/03/html-img-with-svg.html Here I've referenced the SVG (as defined in test 5) with an img element instead of including it inline. This doesn't work in any browser. Except for IE9 the browsers don't even show the included photograph. IE9 shows the photograph, but neither links nor tooltips work. Due to privacy security concerns, an svg will not fetch any external content when it is referenced by an img element. ... However, the HTML living standard features the picture element to allow authors to declaratively control or give hints to the user agent about which image resource to use, based on the screen pixel density, viewport size, image format, and other factors ( https://html.spec.whatwg.org/multipage/embedded-content. html#the-picture-element). The SVG solution discussed above references the image by a different SVG mechanism. Note that it's perfectly fine to reference svg files from a picture element, see e.g http://sarasoueidan.com/blog/svg-picture/. -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Thoughts on the nav element
At first sight I wouldn't define this case so impractical or senseless. Looking at your example it looks like that the nav element is related with the site itself (e.g. other articles, other sections of the site), not with the page. If you had a heading element for the whole site (e.g. the site name), you'd set it above the nav itself. I don't know your language standards, but IMHO the title of the main article of the page is not strictly meant to define the title for the page itself, luckily there's the title element in head to do that. 2015-03-24 15:49 GMT+01:00 Reinier Kaper rp.ka...@gmail.com: Hey guys, I've been worrying (maybe too much) about the nav element lately. In my experience, it has become more of a burden than a help when it comes to the document outline. The nav element forces a new outline section, therefore requiring a heading and (implicitly) requiring a heading to precede the nav element as its parent. Main navigation tends to be at the (physical) top of the document, forcing a heading to precede it is not only impractical, but also irrelevant. Let me demonstrate with a practical example: body header nav h2Navigation/h2 ul.../ul /nav /header main h1Page/article title/h1 p.../p /main footer.../footer /body This will break the outline, as the nav element (regardless of the heading used) will create a new part of the outline and missing a preceding heading. Unless you have a fixed position navigation/header this will not fly from a styling perspective and simply makes no sense. It's completely normal to start with the header of a site/page, including the (global) nav, instead of the site/page title. I would like to see a discussion as to making the nav not sectioning content, but behave more like other semantical elements that don't force part of the outline. If more examples are required I can create a small Gist or something. Thoughts? Kind regards, Reinier Kaper.
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
For the first time in my life I support JavaScript. But I want to see where this idea will go. Here other 2 virtual cents: please, if it ends up as a way to improve the template element somehow compatibly with the current standard, and if it reveals to be viable, try turning it into a proposal for an HTML5.x feature instead of brand new stuff. 2015-03-25 0:50 GMT+01:00 Michael A. Peters mpet...@domblogger.net: I see JavaScript as a useful tool that is seriously abused by many devs, I'm against this. But if you do it, make damn sure it has proper CSP support. On March 24, 2015 2:18:53 AM PDT, Bobby Mozumder mozum...@futureclaw.com wrote: https://github.com/mozumder/HTML6 I’ll be updating that Github with more ideas and refinement about the proposal with occasional feedback into this list. Since this is getting some attention it’s probably better to place the ideas in a setting that can be updated/modified than to discuss it informally via email over here. This is still at the concept phase and I’ll be looking at feedback from other people as well as other frameworks to see the good they offered as well as what caused them to fail. In this version, a key change is that I added an MREF property to A elements to separate the canonical URL from an API URL, and a RECEIVER property to specify where the API data loads: A href=“http://www.mywebsite.com/article-2.html; mref=“http://api.mywebsite.com/article-2; receiver=MyArticleData The MREF will maintain backwards compatibility. You can use the same web page in an older browser and it operates fine, it just won’t load API endpoints, but will reload full page from the HREF. And previously I had a MODEL property in place of RECEIVER, but that's the overall model’s outlet for all elements, not a receiver model, which can be different. Adding a MODEL property would load the model’s properties into the HREF and/or A element. I also changed the fixtures in the example from XML to JSON. I always thought XML was more readable when mixed with HTML, but it looks like people prefer reading JSON? Meanwhile, it looks like the people most into Javascript are against this, and the people that prefer to avoid Javascript like this. I get that most people here are in the “Javascript everywhere!” camp but there definitely is a large class of people out there that prefer to minimize their use of Javascript whenever possible and just want to deal with the declarative HTML system. These are content managers, and Javascript components are largely in the UI design domain, not the content domain that many web developers are coming from. How many UI design experts are out there? And how many of them like working with Javascript, instead of Swift or something else? You’re competing against that. Also I feel you shouldn’t have to prototype new HTML elements as Javascript components to advance HTML. That’s a huge barrier to its development, as now you need to do that first. Very few people will do so for a standards body. The components they make are going to be very specific to their needs. Plus, browser makers aren’t going to write them, so you just forced them to wait for someone else to design these components first, when they already know the problems their users are experiencing and can fix them already. And if your site can do it with a custom component then why bother putting it into the standard? Finally, aren’t people already doing this sort of prototyping anyways with the Javascript frameworks? At a high-level, they’re all basically prototyping an entire MVC use model, with just implementation differences between them. Isn’t that enough to cause HTML to be updated to fit this MVC design pattern? It’s a basic issue in the design of the web. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com mailto:mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com http://www.futureclaw.com/ twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder http://www.linkedin.com/in/mozumder -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [whatwg] Page refresh interface
why doesn't the document interface expose the refresh timeout? Because nobody implemented it and nobody asked for it (until now). I don't know whether to feel proud or guilty about that. http://www.phpied.com/files/location-location/location-location.html . This list does not show that anyone wants to read or write to meta refresh. Overwriting meta refresh is pointless, as the Refresh timeout doesn't change. Writing it would perhaps be impractical as it cannot be changesd once set. This list only shows a bunch of ways to achieve the same behavior. Having a writable property would allow e.g. to delay the refresh Why is that useful? Let's say, for example, that Refresh could be delayed if another timed event is happening on the page (say, for example, the page has a video which is paused or has a buffer delay) or even to stop the pragma refresh instruction and replace it with a timed AJAX recall of specifi contents, maintaining a nonscript whole page refresh for cases where scripts are disabled/unavailable. You can use noscriptmeta .../noscript. Is that sufficient? (It fails when scripting is enabled but the script fails to run for other reasons.) No, it isn't at all e.g. in XHTML syntax where noscript cannot be used. And in general noscript has the issue you underlined: if script is enabled but it fails, then noscript is not considered. How about providing a link that the user can follow? This is indeed my solution. The classic See if there's something new. Click here! link. But users are also getting used to auto-refreshing content and I think that for this specific case it could be more useful to have a stoppable timeout, rather than a link to be specifically navigated. Why is it useful to read the timeout and url? This is a little bit of a personal choice. Let's say I have a page with a specific content which is updated at specific intervals of 80 seconds (or at least it is useless to check for updates in shorter periods). This interval is set with a Refresh header (http or meta). In js-capable UAs I can specify a timed AJAX to update the specific content. The time for that, of course, is the same: 80*1000 milliseconds. Now, of cours I can specify both things. But I usually hate writing properties twice, and I also hate hardcoding properties in scripts: if next month timed updates start being served every 40 seconds I have to change the timeout in 2 different places. On the other hand, if a document.refreshTimeout existed, I could use it directly inside the AJAX call (timeout = 1000 * document.refreshTimeout). I think Refresh as an HTTP header is not specified anywhere, so per spec it shouldn't work. However I think browsers all support it, so it would be good to specify it. Indeed. It was Netscape-specific but it's widespread now (that's why we have a meta http-equiv=refresh surrogate).
Re: [whatwg] Responsive image maps
why not improving an existing feature See https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 Yes, I think I should have expressed it better. Why not improving *this* specific feature? I'm aware that older elements could end up being incompatible with use cases they have served as of now. That's why, instead of changing something, I guess it's better to *add* something, so that legacy UAs keep on behaving as they can (and probably rely on polyfill) while compliant browsers treat new features (elements, attributes, etc.) properly. You can see my original idea at the beginning of this thread. What I proposed is to add an attribute to map element, let's say viewbox or sizes. This attribute shows the width and height (properly separated by space or comma) for which areas coordinates are intended. E.g. map id=resizable name=resizable viewbox=640 480 area href=rectangle.html type=rect coords=0,0,320,120 / /map Now, suppose this map is applied to an image resized to 800x720. areas have to be resized as well, according to proper ratios. So horizontal coordinates (odd positions in the coords list) are to be stretched them by (800/640) = 1.25 times, while vertical coordinates (even positions in the list) by (720/480) = 1.5 (just to handle cases where the original image ratio is stretched). So the adjusted coordinates would be (0*1.25,0*1.5,320*1.25,120*1.5) = (0,0,400,150). As said, the only problem would be with circles which should be stretched into ellipses when ratios are not equal. - resizing does not apply on old maps (without this attribute) and they probably rely on resizing scripts. - maps provided with viewbox attribute are resized natively on compliant UAs. - there should be an associated property to be recognized, so that polyfill support can be provided on new maps *only* in those browsers which do not know how to handle @viewbox and the resizing mechanism. I hope it can be done as easily as it can be described.
Re: [whatwg] Responsive image maps
Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Cheers, AR
Re: [whatwg] Responsive image maps
One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ
Re: [whatwg] Page refresh interface
Simon: I think extremely few actually care about XHTML, but the other issue is probably more relevant. I think that the spec takes care of XHTML and that there's a W3 candidate recommendation spec about polyglot markup. XHTML addresses some issues and creates others, but actually I trust it for some reasons (it's too offtopic to discuss it here). You can access the information by reading the attribute on the meta. You can't read the Refresh header, but then just use meta instead. My issue was to read both, but as meta scenario is standard, you're probably right. Still no way to stop it, though. I like your proposal of modifying behavior by acting on meta tag very much, it's what I tried to do initially, only to discover that things don't change. Yes! You still haven't demonstrated that anyone but you want the ability to stop a meta refresh, though. I guess it's extremely difficult to demonstrate what people want to do when a feature is not currently available. In order to do this I should analyse all the scripts containing a window.setTimeout refresh and tell whether there's an event stopping the timeout (currently the only option for achieving a similar result). In addition to this, I hoped someone in the mailing list could tell if it's useful or not. To Niels: Meta refresh is an ancient quick hack from the Netscape/IE4 era to declaratively specify a reload/redirect intent, *without programming*... meta is not ancient stuff at all. It allows a refreshing where scripts have been disabled. There's a lot of reasons for a user to disable javascript and I don't think stopping refresh is the primary goal. Maybe s/he wants to prevent popups or cookie interaction or anything similar. Or yes, s/he wants to get rid of refreshing. But there's a separate instruction for that. It is explicitly defined that only the user can cancel the redirect, not the browser. This conforms to the fact that only user configuration options and dialogs exist (in some browsers) to influence this behaviour. If by not the browser you mean that stopping refresh is not meant to be automated, then I agree. Why stopping a feature that is instrumental to the page (as the author has set it for a reason), UNLESS the user him/herself has chosen that for UX it's better to stop reloading? If I said the browser above, I meant that the browser should provide users a way (dialog etc.) to achieve that. As you say, to achieve that where it's needed and on a specific case-basis (I think IE is wrong when it prompts authors to disable refreshing everywhere). meta is mainly still supported as a fallback mechanism for non-JS-supporting UAs, but see more graceful degradation... Not for non-JS-supporting, but for JS-disabled too. And, yes, the idea behind my proposal was to rely on a nonscript native feature and to build on it, so that when JS-enhanced solutions fail (for whatever reason), a native fallback is provided. As the spec says (for the noscript case, but I guess it's a good thumb rule): it's generally better to [...] instead design the script to change the page from being a scriptless page to a scripted page on the fly someone who actively elects to use a non-JS UA does so to prevent *any* automatic behaviour Does disabling JS stops CSS animations, form validation, details expansion, table@sortable reordering (when it will be supported), video elements, plugin instantiation via object, and label-control association as well? I think that in modern scenarios a lot of automatic behaviours can be achieved in several ways. Stopping JS is stopping JS. What WCAG approved 14 years ago is reasonable, but it came before some of these features. Unless each of them is disabled separately, or unless there won't be a command prompting users to disable all automation and turn a page into a static document, I don't think that disabling JS means anything more than that. It's authors' responsibility to make refresh accessible (either with JS or with native http(-equiv) refresh). And in addition to this, I have to point out that native meta refresh can be stopped in some UAs without preventing all nice things JS can do.
Re: [whatwg] Page refresh interface
That's evidence that I'm not smart enough. I never search on StackOverflow, I usually g***le it out. Some fellow people who want to stop the power of meta, then. (the first 2 questions for sure, and even more below) If meta were changeable or removable before the refresh action is fired, then it would become a very powerful native instrument on its own and a useful fallback for scriptless cases (i.e. where script is not supported or disabled). And I guess this would remove the need for a standardisation of HTTP refresh header, which is not declared, and perhaps not evident/useful e.g. on page caching. 2015-03-26 14:09 GMT+01:00 Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 13:11:15 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: You still haven't demonstrated that anyone but you want the ability to stop a meta refresh, though. I guess it's extremely difficult to demonstrate what people want to do when a feature is not currently available. In order to do this I should analyse all the scripts containing a window.setTimeout refresh and tell whether there's an event stopping the timeout (currently the only option for achieving a similar result). In addition to this, I hoped someone in the mailing list could tell if it's useful or not. Alternatively you could check stackoverflow. http://stackoverflow.com/ search?q=stop+meta+refresh Would any of those benefit from being able to stop meta refresh, and JS-only redirect or noscript are not enough? -- Simon Pieters Opera Software
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby, the major criticism you have received about your proposal is that you aren't considering at all any other party involved in this subject. Correct me if I'm wrong, you cite no user agent responsible for support, nor working groups or anything loosely resembling to that. You are providing a very useful insight on how *you* see the web. And you also provide a feedback based on the experience of high-school Tumblr girls (why should she learn how to use Angular? However, there's nothing bad if she learns something new). The fact is, your proposal cannot be labeled as HTML6 Web needs something new. And however your last messages do show that the proposal itself is not strictly related to read/write Web as you claim. In fact, the main reasons you cite behind your proposal are responsiveness and full-page reload latency. Which are real problems, for sure, but not in the sense of read/write, they're rather a matter of UX. A relative matter which does not make the Web largely unusable, and if you have doubt about it just have a look at ChromeExperiments and see what can be done with current poor methods. If what you need is localised content load, you have some features you can use as of now. For example, you can use nested browsing contexts, which also offer a layer of protection in the form of CORS restrictions, sandboxing and MIME type declaration. You want to get rid of these things? Use XHR, its support is native. As you said, you are not against JS itself, but against writing more Javascript than necessary. If you have the means, push towards a more pervasive standardisation of current JS implementation, so that there will be decreasing need for polyfills and syntax standardisers (with your proposal, there'd be a need for a polyfill as well until it doesn't become supported on new UA versions *and* new UA versions completely or substantially replace legacy versions). You still want more? Don't focus on changing a web page content. HTML is still a declarative language after all, and there's nothing bad with it. It's the purpose which originated it. Of course there's more now, but the examples of websites or web apps you cited don't generally change the content of a page, they integrate it, adding more items to the page as time passes and events happen. So, as I said some messages ago, why not focusing on template? It can add new elements to the existing document, it's HTML5 so you will have no chance of proposing your language, but you can still work fairly well with it and with its margins for improvement. Current spec suggests how to use it with a JS framework, why don't you elaborate a proposal where template is able to load and parse its own content-to-be? (Of course you can even imagine loading a page which is initially empty, with just a declaration for a template, which adds content at runtime. But it is different from altering current content, a kind of operation that no web designer would desire to be natively executed). And finally, consider that JS complexity and JS memory load are 2 different aspects you will have to face with a brand-new language or featureset: - complexity deals with richness of use cases. When dealing with external content load you have to consider its origin, format, language, connection delay time (you focus on mobile experience, so you know what I mean), its parsing. You have your mind standards, but you can't think things go always ideally, nor you can consider that everybody uses the same structure you have in mind. JS is flexible in this, as it manipulates current DOM structure. Would your native implementation be flexible as well? (side note: if you look at template, its content is really flexible, as it allows as content model lists, tables, subsets of tables, menus and definitely all flow content subsets you can imagine.) It also deals with security. HTML cannot be stretched to execute direct SQL commands (what if those commands are maliciously altered? Do you guarantee instructions integrity? Or perhaps you provide a level of abstraction between HTML6 instruction and DB instruction? This only translates complexity from one language to another, you see), nor to directly respond to server-triggered events (you can imagine the issues of maintaining an open channel with the server in order for it to fire content loading events, both on the side of performance and security). - memory load is a completely different case. Yes, in order for a framework to work, you have to deal with downloading and compiling it, then it has to be executed. A native feature doesn't need downloads, but it makes UAs heavier when they have to deal with all the subtleties of content handling. You are suggesting that a UA behaves as a client for a specific server of your web app, in a 2-way interaction (you can talk about page and all, but the actor in a MVC as view and controller is the browser itself). Can you guarantee that the additional work managed by the user agent does not
Re: [whatwg] Responsive image maps
The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear The main difference between native SVG implementation and native area implementation (map/area scenario lets you small room for maneuvering, so it's native anyway) is that image maps, using tab navigation, don't expose active area. On Chrome there's a large rectangle highlighting the area (or areas in case of link spanning over multiple items), on every other platform there's no native highlighting at all. It's true, you can do it with CSS, but in image maps it's already implemented. As said, it's only a matter of implementation though. Going further, it will be redefined. The fact is always the same: as it's all a matter of implementation, I strongly believe that a mean of natively resize maps should be implemented anyway. You are right, SVG is more flexible with CSS and JS support, but flexibility comes with a cost: those rules have to be defined. Tabbing through an svg probably works best if the svg is inline in the html document For the purpose of this thread, embedded SVG simply wouldn't make any sense. We are talking about links connected with the subject of the document, it goes over the purpose of the image itself (see my note about relative paths above, too). However, there's another point, which IDK if can matter. Maps can be included at any point of the document. With some CSS they can be used as out-of-context item lists, and they can also be reused for different maps inside an image, while SVG have to be repeated. 2015-03-31 16:02 GMT+02:00 Erik Dahlström e...@opera.com: The active area in the svg is whatever the active graphical shape is, I don't quite understand what you mean that it's unclear. The active shape can also be styled with css based on :hover or :active rules, for example to add an outline or to do some sort of visual highlighting. For controlling the tab order there's the tabindex attribute (added in svg2), which has the same behavior as in html. Tabbing through an svg probably works best if the svg is inline in the html document. Support for tabindex in svg is implemented in Blink and WebKit already. On Wed, 25 Mar 2015 21:24:04 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: One of the 2 objections, I'd say. But the second is probably a matter of implementation. SVG makes it unclear what's the actual active area when navigating through tab key. 2015-03-25 19:32 GMT+01:00 Tab Atkins Jr. jackalm...@gmail.com: On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Instead, we start by figuring out what problems need solving. Which is what has been done for this subject, I guess. PROBLEM: image maps, intended as shaped link areas related to specific regions of an image are a fairly requested feature. Unfortunately, as current solutions are not responsive and they can't fit to how images are defined in a modern scenario, with scalable size and art direction, authors have looked for workarounds, script-enhanced or non-native (Flash maps) solutions. POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where 1. CSS has a poor range of shapes 2. See above for SVG 3. area coordinates are absolutely defined. PROPOSAL: As SVG map is not viable at all in complex picture scenarios, and not easily viable in simple contexts, authors could benefit from map versatility. So a viable solution *could* be to improve a feature in order to make it responsive. The Map element improvement consortium is not an organisation I want to mindlessly support (basically because it doesn't exists). And unfortunately I tend to be verbose when I start writing. So in my last message I tried to make it shorter and I chose terms incorrectly. Note that we *should* just be able to use picture in SVG, which helps that solution. This is generally useful (we want responsive images inside of SVG, too), and afaict, removes the only objection to SVG. ~TJ -- Erik Dahlstrom, Web Technology Developer, Opera Software Co-Chair, W3C SVG Working Group
Re: [whatwg] Page refresh interface
Therefore he gets a site without non-declarative interactivity, from complex form validations and animations to complex page refresh logic. Native form validation, CSS animations, still keep working with JS disabled. Again, disabling JS does not mean refusing animations. Does this mean that meta refresh should be avoided altogether and replaced by JS? I would argue yes, but that's a different discussion. It was retorical. I think not. It's just a powerful mechanism that can work when users want to disable JS for other reasons which are *not* necessarily to avoid refresh, as said before. http://stackoverflow.com/questions/3252743/using-javascript-to-override-or-disable-meta-refresh-tag This thread is quite full of examples with authors trying to remove meta after it is loaded or to hide it inside noscript, two not viable solutions. I'm not looking for a native solution for *all* use cases. I like using JS in several scenarios, but I also like providing pages with a fallback as you said. Among the worthy points of this discussion there's probably this: it's not important to modify meta refresh timeout, as that would need JS to be changed and so a window.setTimeout is enough. So let's put it simple: can refresh be stopped when removing meta refresh element? No. Could it be requested? I wish so. 2015-03-26 16:38 GMT+01:00 Niels Keurentjes niels.keurent...@omines.com: The point is, what happens to the JS-only solution in cases where JS is not usable for any reason? It will not run. The user has chosen to either disable JS or use a non-supporting UA. Therefore he gets a site without non-declarative interactivity, from complex form validations and animations to complex page refresh logic. Does this mean that meta refresh should be avoided altogether and replaced by JS? I would argue yes, but that's a different discussion. Much like browsers still probing for /favicon.ico on every site, it's a legacy mechanism that survives because it's being used. Having said that meta refresh is an ugly solution that has far better solutions, but as it's well-documented and well-supported it's fine to use for the simple use cases it was designed for. If there's a more complex use case, such as pausing/postponing/cancelling/prolonging the delay before the refresh, it makes no sense in my opinion not to use setTimeout in the first place. I just don't see why you would want 2 rich mechanisms to solve the same problem, one of which is inherently unwieldy because it requires extra properties/APIs to be exposed. As said: if you want to modify the refresh, you're using JS. If you can use JS, you can use setTimeout. If you want to use `meta` as a fallback, it's only a worthy fallback if it exposes the exact same behaviour. It only does so if you're not modifying the timeout after load, which makes the whole discussion moot about being able to modify it. Niels -Original Message- From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Andrea Rendine Sent: donderdag 26 maart 2015 16:15 To: WHATWG List Subject: Re: [whatwg] Page refresh interface ..Simon, there's no use case where meta cannot be substituted by a JS-only solution. The point is, what happens to the JS-only solution in cases where JS is not usable for any reason? Usually fallback content can be hidden or removed somehow, but meta makes it impossible. Does this mean that meta refresh should be avoided altogether and replaced by JS? 2015-03-26 14:48 GMT+01:00 Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: Some fellow people who want to stop the power of meta, then. (the first 2 questions for sure, and even more below) http://stackoverflow.com/questions/28435865/can-i-stop- a-meta-refresh-using-javascript http://stackoverflow.com/questions/16289798/button-to- temporarily-disable-stop-meta-tag-refresh These can be solved with JS-only refresh, as far as I can tell. Any others? -- Simon Pieters Opera Software
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
I'm going to say something not nice. Blame me freely. Back in the earliest days, it was pretty easy to publish a page of text... Easy enough for the average writer ... The fact that writing a simple document has become a programming job - between a lot more HTML functionality, CSS, and JavaScript - is (IMHO) a HUGE barrier to the basic concept of a read/write web. Yes. It has.For a long time everybody could write Web pages that, though inaccurate, reached their goal somehow. Which is why current HTML spec is full of - attempts to stop non-semantic use for elements (the edge case of layout tables should teach something), - error-handling rules, - complex paragraphs describing legacy compatibility with previous versions, - rules for correctly handling non-standard features, or existing features badly used (see object@classid et al.) - a huge list of non-conforming elements derived from presentational HTML or from browsers war era - and much more. Indeed, leaving some degree of freedom to authors allows a broad field test for what's good and what's missing in features. Sometimes it also allows that features are *invented* on field, only to become standard afterward. But IMHO publishing a web page is not an easy task. Nor it is required to be such. A web page isn't a Word document, even if Word can create web pages. Or, which is better, everything in content publishing is fun and games... until publisher and public are the same. When writing for other users, for interoperability, for potentially unknown or custom or *evolving* platforms, the it works for me approach is no longer applicable. Everybody can write content for a web page, of course, but publishing it in increasingly complex, visually attractive, accessible, semantic ways requires programming skills as well as any publishing sector requires its own skills.
Re: [whatwg] Responsive image maps
My idea started from considerations about the picture element itself, so I agree with Martin, a native feature to resize image maps should wrk with the picture/img scenario. IE11 doesn't scale SVG as noticed about previous versions. As a side note, I have to notice that selecting areas in SVG with tab navigation behaves inconsistently. (tested on Chrome, Opera, FF, IE latest versions at the time of writing): - Chrome highlights the active regions with rectangles encompassing the areas. Note that if the area is a non-rectangular polygon, or a circle, or worse a group of areas, the highlighted region will also include non-active areas and I don't know how confusing it can be. - Opera does not allow tab navigation on the examples provided by Martin. IDK if it needs tabindex as well, but simple examples can be navigated only with click. - FF and IE allow tab navigation, but they don't highlight regions at all. On the other hand, in map scenario only the area is highlighted instead, and with the correct shape, in all user agents. Side note #2: the correct syntax is a xlink:href=, as done in Martin's examples, not a href, as @href is not a native attribute of SVG for what I know. It seems that using SVG with a elements is an adaptation of an existing element for a different purpose. It is useful in some scenarios, especially when the image itself is generated in SVG and associated with links (and maybe other visual hints/effects directly applied on SVG elements), but map is the native feature to do so, it's usable, it's also user-friendly though it has limitations. It would probably be better to make it more modern and allow authors to choose as they prefer. 2015-03-22 15:06 GMT+01:00 Martin Janecke whatwg@prlbr.com: I've done a few tests and provide links to them below the following discussion. Am .03.2015, 20:30 Uhr, schrieb Tab Atkins Jr. jackalm...@gmail.com: SVG is highly accessible. Yes, SVG a elements are followed just like HTML a elements, and yes, screenreaders do read out desc elements when appropriate. Nice! Am .03.2015, 21:15 Uhr, schrieb Tab Atkins Jr. jackalm...@gmail.com: On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine master.skywalker...@gmail.com wrote: About SVG, I made a couple of tests and they are far from being comprehensive, but this is the fact. SVG image maps need to define 2 elements for each area, i.e. the element itself and its associated hyperlink. That's really not much: svg width=... height=... image src=foo ... / a href=target1polygon points=... //a a href=target2rect ... //a ... /svg The markup complexity seems to be about the same as using img/map/area, especially if you accompany it with prose like the example in https://html.spec.whatwg.org/multipage/embedded-content. html#the-map-element shows. While inline SVGs are somewhat more verbose and complex, I'd say it's justifiable. They also bring advantages like being able to link multiple disconnected areas to a single resource with a single hyperlink. svg elements can be resized by the CSS 'width' and 'height' properties just fine. Yes, though my third test showed an inconsistency that might need to be addressed. .: Tests :. I've done tests with Internet Explorer 9 (IE9), Opera 27 (Opera) on Windows Vista and Firefox 36 (FF), Google Chrome 41 (Chrome), Safari 8 (Safari) on Mac OS 10.10. All test pages show a photograph of a dog and a few items lying on the floor. The goal is to display the photo with 800px × 600px in windows that are larger and have the photo resize automatically in smaller windows, so that there's no horizontal scrolling necessary. The dog and all the shoes in the photo are active areas: they are supposed to show tooltips when hovered and lead to the Wikipedia articles Dog and Shoe when clicked. Test 1: https://prlbr.de/2015/03/html-map.html The first test uses just the classic map and area elements associated with an img. It works in all browsers in big windows, but when the window is resized to be small, it works in no browser as required, because the coordinates in the map's area elements don't scale with the image. This test illustrates the problem that needs to be solved. Test 2: https://prlbr.de/2015/03/html-map-with-javascript.html This test uses the HTML code from the first test plus JavaScript code, which manipulates the coordinates in the map's areas after the page has loaded and whenever the window is resized. This works in all browsers as expected, if JavaScript is enabled, and demonstrates what needs to be achieved. However, this does not work in any browser with JavaScript disabled. This is not satisfactory. I'm not aware of a use case where you don't want an image map associated with an image to be resized whenever the image is resized. So resizing of image maps in accordance with their associated image should really be possible without always adding a JavaScript program. Test 3: https
Re: [whatwg] Page refresh interface
Someone also said that once it used to work or that it no longer works, even if I don't feel I can trust it. Also consider that noscript is somehow blunt as it detects whether JS is disabled, but its content is not parsed if JS is enabled but for any reason it doesn't work. 2015-03-26 20:21 GMT+01:00 Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 17:10:56 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: http://stackoverflow.com/questions/3252743/using- javascript-to-override-or-disable-meta-refresh-tag This thread is quite full of examples with authors trying to remove meta after it is loaded or to hide it inside noscript, two not viable solutions. It looks like the person who asked the question in that thread would be happy with noscript had it worked in the cell phone browser he was interested in. But it would be better without noscript, certainly. Also several people assumed that it would work to remove the element to stop the timeout, which is entirely reasonable. -- Simon Pieters Opera Software
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
I don't want to openly oppose to this project, as I'm anyway curious about how it will be developed. It's only that I have seen a lot of elements used outside their proper dynamics. I don't see HTML as a templating language, but it's probably because I'm tied to current use cases, so I don't see any further. Anyway, yes, I write my pages so that their content is to remain when served to client. Of course I would add more to the preexisting content, given the circumstances, but not to change what's already there. Besides, I invite you to consider, throughout the development process, a possible role for template element. Instead of creating something completely new, some features could be added to make it more complex and more complete. It is now a container for markup that can be reused by script to show content. Why not making it able to load its own content, then? 2015-03-24 21:01 GMT+01:00 Bobby Mozumder mozum...@futureclaw.com: On Mar 24, 2015, at 8:19 AM, Andrea Rendine master.skywalker...@gmail.com wrote: As an author I shall offer my 2 cents too. First off, I'm for native implementations and all that markup and CSS can do on _existing_ content. Thus said, I prefer having JS manipulating the content with AJAX than having the markup doing that. Apart from the concept that markup itself is being pushed too far, from an instrument capable of specifying properties for its content to something acting on its own, I think there's more potential for security issues than for genuine manipulation. Maybe things will move towards that end from now on, as websites have to look like web apps and this means that they have to be apps executed on a browser platform, but I personally prefer an ideal model where - html provides static content, i.e. content which does not change when looking at the page structure itself - css provides ALL the graphic/presentational stuff and even some interface, (everyone can imagine what can be done with :target or :checked selectors...) - js provides dynamic content, i.e. whatever is to be considered part of the content itself when actions are executed or events are fired. Let's see what happens, then. This was just an idea. In this proposal, HTML would turn into a templating language. A template is a perfectly valid document specification. You see document templates everywhere, at the office supply store, in Adobe inDesign, and so on. Besides, when was the last time you actually wrote a static HTML file? Does anyone do that? For every web site, people actually write templates, not HTML code. This proposal standardizes on the idea of using HTML for templates. -bobby --- Bobby Mozumder *Editor-in-Chief* FutureClaw Magazine mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder
Re: [whatwg] Page refresh interface
..Simon, there's no use case where meta cannot be substituted by a JS-only solution. The point is, what happens to the JS-only solution in cases where JS is not usable for any reason? Usually fallback content can be hidden or removed somehow, but meta makes it impossible. Does this mean that meta refresh should be avoided altogether and replaced by JS? 2015-03-26 14:48 GMT+01:00 Simon Pieters sim...@opera.com: On Thu, 26 Mar 2015 14:37:17 +0100, Andrea Rendine master.skywalker...@gmail.com wrote: Some fellow people who want to stop the power of meta, then. (the first 2 questions for sure, and even more below) http://stackoverflow.com/questions/28435865/can-i-stop- a-meta-refresh-using-javascript http://stackoverflow.com/questions/16289798/button-to- temporarily-disable-stop-meta-tag-refresh These can be solved with JS-only refresh, as far as I can tell. Any others? -- Simon Pieters Opera Software
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
It's sad indeed, as it seems that best practices are seldomly followed and poor coding is the way. However, some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag Actually progress is native only in its attribute definition and default rendering. It still requires JS in order to access its @value in write mode. On the other hand, I suppose that complete implementation of details is delayed by the fact that it's defined in terms of shadow DOM, and no real DOM adjusting is expected for it. Not every browser is ready for this further level of interface, probably. 2015-03-28 3:45 GMT+01:00 Michael A. Peters mpet...@domblogger.net: On 03/27/2015 06:51 PM, Miles Fidelman wrote: I've been reading through the discussion thread, all of which seems to jump immediately into the weeds of specific details of the proposal. I'm amazed that nobody has yet commented on the implicit premise, which I read as: - JavaScript is a processing pig - with the addition of a few, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. In HTML5 some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag, is still not universally supported by modern browsers requiring JavaScript fallback. I don't know why it takes the browsers so long to implement, but it does. The problem with JavaScript is that fewer and fewer web devs care. Rather than picking a framework (like jQuery) and sticking with it, they copypasta JS they find around the web (often in violation of the license) and add whatever framework that snippet depends upon. Few people care about passing their JS through tools like JSLint, and many pages still have dozens of external JS references as well as numerous inline scripts. They just don't care. And that is hard to fix with standards because they don't care.
Re: [whatwg] Thoughts on the nav element
After a mail confrontation with Reinier, as well as some very simple models I saw at work, I have to admit that I support this idea. nav has a strong semantic value, for sure. It deserves UAs to easily highlight navigation elements. Thus said, is it really needed that nav necessarily defines a section? I think not. A first point is what Reinier underlined. With a structure as follows: [header with no heading elements] [navigation] [main with its own heading elements] an author would end up with an ugly and impractical (as stated by Reinier himself) structure: an untitled body, a navigation, and a main content presenting a heading, which is no longer the page content title as it was logically intended. Some authors (I'm among them) prefer different structures with one title for the page and one for main content, but defining main element as *not* sectioning allows a more agile structure... actually made non viable by a sectioning nav placed before main (and note that this is both a layout choice AND one dictated by logic, as site navigation is not to be considered part of the main content). On the other hand, consider a long navigation element enclosed in an aside. The spec suggests it can group a series of nav elements, but even a single nav list qualifies as content tangentially connected to the page topic. But aside is sectioning content too, and when using a single nav in aside, it forces an unnecessary further nesting [body] [aside] [nav] also forcing authors to put different titles when they want to avoid the poor default choice of Untitled xxx element. Having a strong semantic doesn't necessarily mean defining a section for the document, as emerged for main element too. I previously suggested that main itself could become a sectioner, but I have to retract because this solution is highly impractical... yes, as well as sectioning nav. This element is not even logically suitable to define anything - it just helps users retrieving navigational structures. Then, if authors need to *also* use it as a sectioner, nobody can stop them from defining it as a section, either implicitly (through a heading element) or explicitly (wrapping it in a strongly sectioning elements such as aside).
[whatwg] Page refresh interface
Hi everybody! A request starting from meta element and its refresh state: why doesn't the document interface expose the refresh timeout? The ideal would be to expose it in read/write mode, as authors have evolved several variants of location.href/replace/refresh/reload. And for several I mean 534: http://www.phpied.com/files/location-location/location-location.html . Having a writable property would allow e.g. to delay the refresh or even to stop the pragma refresh instruction and replace it with a timed AJAX recall of specifi contents, maintaining a nonscript whole-page refresh for cases where scripts are disabled/unavailable. But even without a writable property, it would be useful to just have read-level properties such as document.refreshTime and document.refreshUrl . Consider that refresh time (along with a refresh URI) can be set by (non-standard (why non-standard?)) header response, a meta element already present (and there can be more than one, as UAs know how to handle this error) or even being inserted at runtime. So it is difficult to access this information without a proper interface. Besides that, the spec says that UAs may expose the time (and other aspects) for a refresh event of the document and it also refers to the possibility for a user to cancel the redirect, while as of now users aren't even informed, let alone allowed to interact with this event.
Re: [whatwg] MetaExtension and Dublin Core revision
Mr. Hickson, please let me know if further details are needed, or otherwise if change proposal will be accepted, at least partially. The more those properties remain there, the more authors can read them and use them incorrectly IMHO. Yours respectfully, Andrea 2015-03-26 18:19 GMT+01:00 Andrea Rendine master.skywalker...@gmail.com: A note about DC.xxx properties. According to the spec, the properties marked in my mail can be used as DC-prefixed, though in the wild the DCTERMS prefix is largely preferred. If these properties were to be used, it should be specified that the correct namespace declaration is *not* link rel=schema.dc href= http://purl.org/dc/elements/1.1/;, but something like link rel=schema.dc href=http://purl.org/dc/terms/;. DC prefix is used with both namespaces for legacy compatibility, but the prevalence of DCTERMS over DC is about 100 to 1. All this does not apply to dc.date.issued, which simply does not exist (the correct property name is dc.issued). You can find all sources for those properties at http://dublincore.org/documents/2012/06/14/dcmi-terms/ Cheers, Andrea Rendine
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Some years ago there were also Internet Explorer 6, proprietary tags,
frameset web pages and the project for DHTML. There also was the idea of
simple JS expressions to be evaluated in CSS. Why does anybody not propose
to restore {expression()}?
Never been a fan of the new is good motto, but saying that things were
better in the past just because they were that way seems odd.
Delfin, you also cite the times (2002) when CSS could be effectively
disabled. Can you imagine a Web without CSS nowadays?
I don't think that Bobby's proposal focuses on ease of use. His model, as
it it planned now, seems quite complicated now. It is a different kind of
difficulty, but still difficult.
And planning to give the coding power to the people by means of
inventing easier things is wrong in its very merit. Javascript itself is
not a difficult programming language. In fact, Mr Mozumder's proposal seems
to lack uniformity because it does not make clear whether the author wants
to oppose the JS concept or the multiplication of frameworks.
Let's put it in 2 separate points:
1. fighting against frameworks is contrary to the very same logic you are
citing as support for Web as it was. It is true that different frameworks
solve the same problem in different ways. Thus authors can choose the tools
which best fit to the project - or no tools at all, but this is the second
point. Yes, there could be a sort of native framework and it will have
its strong points as well as its liabilities, and if it doesn't cover a
specific document structure it must be switched in favor of another. I take
it for granted that Bobby has no ambition to write the ultimate framework,
and I'm also sure that he couldn't do it by himself, were he going to.
But it is also true that frameworks add weight to the page. A weight which
is only partially reduced by e.g. using Google CMS to serve frameworks like
jQuery, considering that if several websites use the same files, then once
a user visits one, the script files are cached. I think that the only, REAL
good point in Bobby's project is this: reducing weight, and thus reducing
loading lag (reduced to 0 when you have nothing to download); and reducing
execution time, as some frameworks have a long time being executed (but
then Mr Mozumder has to prove that UA native implementation will be faster
- it's a joke, of course. Mr Mozumder cannot prove anything about that)
2. fighting against JS itself is a completely different case. I have
discussed it in depth above and I guess nobody likes to re-read things.
JS has been part of making web pages for a long time now. It is the
necessary integration to HTML and CSS because neither HTML nor CSS are
meant for content manipulation. HTML exposes an API, the DOM, and that API
can be used for a lot of things. This is the good point of JS. It allows
authors to work on elements and attributes, as well as interface
attributes, methods and properties using a much more fine-grained structure
than simple HTML. To make an example, when loading an external content you
can access different properties allowing you to easily find out origin,
HTTP call response code, loading status and so on. You have nothing to test
it in native HTML, unless you say that calling, e.g.,
model.data.status property or model.data.parse() method is HTML. It
isn't, it's JS.
The majority of frameworks were born to provide a solution for a different
problem: object standardisation across platforms. Think about AJAX
standardisation made by jQuery and other frameworks: it was necessary when
there were at least 3 different ways to do a simple XmlHttpRequest.
It's simple as that. If there were a deep wish to find a common platform
for features implementation (this wish is increasing, though), you wouldn't
even need frameworks. You'd still need JS, though, in order to execute XHR,
in a standard, 360°-wide scenario. That standardisation is still unachieved
for JS. So does anybody want to say that JS is not Web for this? Fine, then
get rid of CSS too, as its implementation is far from being uniform.
If you want to lower the barrier to entry in Web design, the right solution
is not to remove complex things. Do you lower grammar standards because it
is too difficult to speak correctly? Do you lower any of your expectations
towards any aspect of life when that aspect becomes too tough? I respect
anybody's effort to make web pages, and I myself am quite new to this. But
each one must do what s/he can do, or learn more things. What is needed for
a better Web is standard. It is a ruleset that can be studied and applied
without thinking Is this solution compatible with that specific version of
that specific browser?.
A final consideration: as JS is a scripting language, it has to be parsed
and compiled. If it presents errors, it cannot be executed and it stops.
With HTML6 you are going to deliver a powerful tool to, say, fashion
bloggers and Tumblr users. Is it meant to have an error handling as HTML
has to do
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby, stop talking about comfort zone and scared programmers and start acting like a person who considers anybody else worth discussing with, instead of a bunch of stupid people acting for their own interest. What you propose is as complex and impractical as a JS framework is. Moreover, an author should either learn very well SQL or learn your variant of the language which is translated into SQL statements, something you seem not to consider. Not ad hominem. I’ve literally had developers tell me everyone should learn Javascript. Example: https://twitter.com/yoavweiss/status/582490158496419840 That's obviously a horrible idea. Why would anyone encourage millions of other people to do more work? Everyone’s time is limited. Why should a fashion-blogger spend time to learn JS to get a responsive high-speed site? They have other things to worry about, like next season’s collections. I strongly hope you are joking. If the fashion blogger does not know how to work with JS, s/he will either stick with ready-made sites or blogs, or ask to someone capable to build the site for him/her. It's not just because anyone can be a fashion blogger, that anyone can build a website too. The former activity needs no skills (apart from some taste, while the definition of taste is quite non-uniform), while the latter needs technical skills, And your proposal will need technical skills as well - not on the JS side, but in HTML. I was talking with a Tumblr power user a couple of days ago about this and she confirmed that all Tumblr kids pretty much know the basics of HTML, somewhat fewer people know CSS, and nobody knows Javascript. sarcasmWell, this means that we must also simplify CSS, don't you think so? all that stuff about media queries, about animation and transitions, pseudo-elements, pseudo-classes, how can poor Tumblr users learn that?/sarcasm sarcasm type=hardIt's a real luck that Tumblr kids, who obviously constitute the bulk of modern authorship, know HTML well enough to also learn your complex two-way control/view model (I still find it complex somehow, I'm not as smart as they are of course. Evidence: I'm stuck in my JS comfort zone)./sarcasm I repeat the assumption I did in my private message, that you haven't probably had the time to read. You seem to swing freely between saying no to JS frameworks and saying no to JS as a whole. When and why you did elaborate the idea that JS is not part of Website building? When did you decide that web pages have to be HTML and CSS and SQL, while half the HTML we have now is also defined in terms of objects with properties and methods? Want to say no to frameworks? Stick to basic properties for objects. Keep on fighting against JS, and you will look like someone who is trying to abandon CSS in favor of font tags and @width/@height attributes because they're simpler. 2015-04-02 10:23 GMT+02:00 Rimantas Liubertas riman...@gmail.com: I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic 2) it changes HTML to something entirely different. 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? That's obviously a horrible idea. Why would anyone encourage millions of other people to do more work? Everyone’s time is limited. Why should a fashion-blogger spend time to learn JS to get a responsive high-speed site? They have other things to worry about, like next season’s collections. The best experience should be on by default, and you need a built-in MVC framework in HTML for that to happen. And fashion designer will be able to use it without learning? Also it is not clear, how are you going to separate M from V from C if it is all HTML. You’ll find that the kind of proposal I’m putting out there is the only viable solution. Your proposal is just a bit of magical thinking, not any solution. I am not sure what problem are you trying to solve. Is that ‘allow non-technical people to build web-sites’? Then you are solving it at the wrong level. Best regards, Rimantas
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Polyfills aren’t going to cover all possible scenarios, either, since they’re going to be limited by test coverage. Some messages ago you suggested that Angular would serve as a proof of concept for your proposal I'm sure you didn't mean to replicate Angular.js with HTML. No polyfills will actually cover all use cases, but it's also true that you are not required to build something usable here and now. You just need something working so that authors and possible collaborators can follow your proposal. I'd suggest you a simple script with modern DOM methods that can be run, say, on Safari/Chrome/Opera latest versions (no need for legacy support), just for Web designers who wish to test how it works. It's easy - an XHR to simulate native call, a server-side script for the API and a bit of DOM traversing for content substitution. Just in order to let people know that your proposal is not a bunch of words. 2015-04-03 6:04 GMT+02:00 Bobby Mozumder mozum...@futureclaw.com: On Apr 2, 2015, at 1:16 PM, Brian Kardell bkard...@gmail.com wrote: Many of simple cases that I see that you could potentially do with your approach as described, at least my understanding of what I've seen so far, can in fact be done today with several frameworks declaratively.. There is competition in the space of how to express it and that is fundamentally no different than if we discussed it on a mailing list, there would be different ideas. The difference is that one involves speculation, no testing and is useless to people in the meantime (and the meantime means years) - very frequently only at the end of that do you find out that 'whoops, that isn't actually what developers need for 70% of real cases' and that scenario is a fundamental loss at almost every level. The issue is that that those simple cases are, in fact, not the norm, you exceed them very quickly and the question immediately becomes 'then what?’. You adapt and change things as needed. But for now you work with the information you have. Again, I’m not trying to create a large comp-sci project with all sorts of theoretical options. I just see a basic user experience problem and figuring out a solution designed to fix that. I hope you agree that there is full-page reload is a problem with the web? If you agree that it’s a problem then we can fix it. Ideally the solution would work with all parameters I previously mentioned (JSON API interfacing, no loading additional JS files, high-school kids can understand it, etc..) Other solutions don’t meet these parameters. Angular/React/etc. requires loading in an extra Javascript file, as well as JS programming, which is why they’re not widely adopted except for JS developers. XSLT doesn’t have a statefully persistent model object operates around weird XML. MDV also needs JS and the models seem tied too close to the DOM, and so on.. The fact that so many people are trying to solve this problem isn’t a good thing. It means there’s a problem with HTML itself that needs to be addressed. HTML really needs to just go ahead and fix it. There's a lot of competition and collaboration figuring out how you create a well reasoned system that allows users the proper balances of power and simplicity and ability to adapt. To answer the same sorts of questions that they answer every day, your solution will involve JavaScript too - as well as SQL and some server-side specifications which will require their own languages and probably frameworks. Those are optional features. The basic proposal offers dynamic pages without Javascript, using pure HTML. I'm honestly not trying to dissuade you here or perpetuate an argument, I'm just saying that your insistence on drawing this line to say 'it's so simple' is, surely you can appreciate, a 'big' statement and it doesn't seem unreasonable for people to ask you to actually show them. Believe it or not, participants in standards bodies have limits to the amount of time and monetary investment they can make into something and there's a lot to do. Getting something started often requires first-movers to show something, even browser makers usually don't just throw an idea out there, they work out a proof of concept with the proposal and show people what they are talking about. It's not unreasonable to think that people ask you to do a little more leg-work before they commit to ...well... even reading more if you see what I mean... we've all got limited time. Right now I’m trying to figure out advanced scenarios or use models where this proposal would be a bad idea. You have any ideas on that? Polyfills aren’t going to cover all possible scenarios, either, since they’re going to be limited by test coverage. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com mailto:mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com http://www.futureclaw.com/
Re: [whatwg] Using @type on code to specify the computer language
Long ago I proposed an attribute for code language because I was unhappy with all the class=language-whatever thing. I proposed @lang because I thought there could be an issue with speech synthesis and languages, but it was effectively pointed out that such attribute does not fit this case. +1 for @type, it is widely consistent to use that for MIME types. But I guess that it will bring nowhere (as usual) unless vendors show any interest for this issue.
Re: [whatwg] Using @type on code to specify the computer language
Mathias, mind that while libraries support using the @class attribute, there's no standard between them about whether to use a prefix before the language or if a prefix is necessary at all. Besides, @class has no semantic value. It's true that the spec suggests using semantic class names (instead of layout-inspired, I mean), but there's no real meaning for that. 2015-05-09 14:48 GMT+02:00 Mathias Bynens mathi...@opera.com: There is a de facto standard here that is already supported by most syntax highlighting libraries, based on this part of the spec: https://html.spec.whatwg.org/multipage/semantics.html#the-code-element “There is no formal way to indicate the language of computer code being marked up. Authors who wish to mark code elements with the language used, e.g. so that syntax highlighting scripts can use the right rules, can use the class attribute, e.g. by adding a class prefixed with language- to the element.” I’d prefer following that pattern over inventing a new one.
Re: [whatwg] MetaExtension and Dublin Core revision
Mr Hickson, I understand now, things are to be tested in the real world. I hope you judge WebDevData a reliable source. I ran some tests on latest WDD dataset (January 2015) All list items below have been searched as value for meta@name dc.date.issued (along with possible variants dct.date.issued and dcterms.date.issued) 0 occurrances (dc.date.issued does not exist in DC spec - probably a copypaste error in the table) dcterms.collection (along with possible variants dc.collection and dct.collection) 0 occurrances (DC spec also defines some details for its properties, e.g. classes, and collection belongs to this category; it isn't a real property to be used in meta elements) dc.(date(Copyrighted|Submitted)|license|m(edi(ator|um)|odified)|provenance|references|temporal|valid) 0 occurrances (DC spec defines the properties above as dcterms., not dc.) dcterms.(has(Format|Part|Version)|is((Format|Part|Version)Of|Re(ferenc|placed|quir)edBy)|re((ferenc|plac|quir)es|lation)|s(ource|ubject)) 0 occurrances (DC spec states that the above properties are to be specified as resources, rather than literals) There are no incorrect uses in the wild of these properties, at least in the group of pages analysed by WebDevData. Probably some authors wanted to reflect the whole DC spec in order to standardise his/her favourite subset of DC metadata, and in doing so s/he made some mistake in copypasting it. Can the table be fixed accordingly? Yours respectfully, Andrea
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
You don't have to show any magnificent markup example with pages of description. You have to show authors how this framework WORKS in real life. With comprehensive use cases. This is a polyfill. As you can find for any other HTML magic you see around. CSS is a different case. Without proper tools, you can only replicate your desired layout with graphical tools (and this is always done). You can't expect that UA vendors build a new product based on your words. Do you have ideas about several use cases and not just one? Build a JS surrogate (you said you know JS) mimicking what future user agents are expected to do. And test it for security and robustness and flexibility. Markup is just words. Tagged words, but simply words. Of course browser vendors will have to do a lot of programming to reproduce your ideas. But first show how your ideas work. And keep in mind that something is not simple just because it starts with and ends with , and for this reason you can call it markup or XML or SGML or HTML and say it's simple. Ok, it's you on the right side and the whole world gone wrong. I'm sure your proposal has gone viral, and the fact you have no contributors, no forks or no answers on Github (apart from Taylor Swift spam) is just red herring. But with a demo, everything will be clearer. And stop criticizing everybody else's work just because it's different from yours. Cheers. 2015-04-02 21:27 GMT+02:00 Bobby Mozumder mozum...@futureclaw.com: On Apr 2, 2015, at 3:22 PM, Rimantas Liubertas riman...@gmail.com wrote: There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic I believe that’s called “programming”. So that poor fashion designer will have to learn to program after all… The browser vendors are the ones doing the programming. They’ll ultimately decide if they want to implement this or not. 2) it changes HTML to something entirely different. To what? HTML already has things like SCRIPT and other features not related to hypertext markup. I don’t know to what, I never saw any examples how your MVC would look like. Would you care to show how something like http://backbonejs.org/docs/todos.html would look if done your way? I have examples in the original message, as well as in: http:/// www.github.com/mozumder/HTML6 -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com mailto:mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com http://www.futureclaw.com/ twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder http://www.linkedin.com/in/mozumder
