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] Responsive image maps
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] 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
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
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 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.
[whatwg] HTML6 single-page apps without Javascript proposal now on Github
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
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
On Mar 24, 2015, at 4:15 PM, Andrea Rendine master.skywalker...@gmail.com wrote: 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? In the proposal I already do list using TEMPLATE elements to instantiate model objects. This would make it the equivalent to blocks in traditional template languages. See: https://github.com/mozumder/html6#further-uses Is that OK? Any other options? -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
[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
Hi Andrea, Yes those are valid points, but the issue I was trying to point out was not the (implied) semantics (they're great and should remain), but the forced sectioning it brings. Although the title is appropriate to carry the page's title, the h1 in general should carry the page's/article's title as well, as title is not part of the document outline. Example: a page about cats on an animal website could have an h1 of All about cats, but it doesn't necessarily mean it should appear before the nav that's related to the site (and therefore precedes the main element for example). Again: the semantics are important and make sense, but the forced section is not practical, nor required in my opinion. To provide another use case: how often do you really find yourself needing a heading in the nav element? I rarely see Navigation as a heading before the actual navigation. Not saying there shouldn't be one, but I think the use cases for it are poor at best. Cheers, Reinier. On 24 March 2015 at 11:08, Andrea Rendine master.skywalker...@gmail.com wrote: 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.
[whatwg] Thoughts on the nav element
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] Responsive image maps
On Fri, 20 Mar 2015 20:22:28 +0100, Martin Janecke whatwg@prlbr.com wrote: Am .03.2015, 13:10 Uhr, schrieb Simon Pieters sim...@opera.com: Please leave out syntax proposals for now. What I think is needed first to drive this forward is: * Use cases. Why do you need this? In general it's needed to allow geometric areas on an image to be associated with hyperlinks – that's what https://html.spec.whatwg.org/multipage/embedded-content.html#image-map says – and to associate areas on an image with tooltips. I've used this to name objects in a drawing (think of helping children or foreigners learn words for things displayed in an image). I've also packed small versions of photographs with different aspect ratios nicely aligned in a single preview image file and used an image map to link those previews with bigger sized photographs (https://prlbr.de/2014/wanderung-wanzer-wittenberge/). I've seen Wikipedia link objects in photographs and paintings (star constellations, people) with active image areas. It's also used for site navigation with fancy design. Those are use cases for image maps. Having them work on different screen sizes, e.g. on smartphones and desktop screens, is the main use case for making them responsive. Thanks. * More examples of pages that work around the lack of this feature. Here's a Wordpress plugin actively used on 7000+ sites: https://wordpress.org/plugins/responsive-image-maps/ In httparchive I see 92 out of ~130,000 pages using jquery.rwdImageMaps.min.js or imageMapResizer.min.js. SELECT page, COUNT(*) as num FROM [httparchive:runs.2014_08_15_requests_body] WHERE REGEXP_MATCH(body, r'(jquery\.rwdImageMaps\.min\.js|imageMapResizer\.min\.js)') GROUP BY page ORDER BY num desc; Of those 92, 17 use variable-size image map: http://www.shitlicious.com/ http://www.1stonlinesolutions.com/ http://www.audio-technica.com/world_map/ http://www.apartmentratings.com/ http://www.unoriginalmom.com/ http://www.bonton.fr/en_4/ https://www.electricobjects.com/ http://www.zeitzuleben.de/ https://www.konami.com/ https://www.ncjrs.gov/ http://www.thehybridshop.com/ http://www.brief.pl/ http://www.foodpolitics.com/ http://www.milegi.in/ http://www.sura.com/internacional/default.aspx http://www.mintvelvet.co.uk/ http://www.oldtimecandy.com/ ...and 3 use art direction image map: http://www.wetv.com/ http://www.kidsii.com/ http://www.hbs.edu/Pages/default.aspx ...and the rest either don't use map at all or use a fixed-width image map. Recently I've modified my personal website to be mobile-friendly – except for all the pages that use image maps with differently shaped active areas, because I didn't have a nice solution for these. That's not an example for a work-around of course, but an example for demand for such a feature. Here's a bunch of stackoverflow questions showing more demand: http://stackoverflow.com/questions/1563299/recalculate-image-map-after-window-resize http://stackoverflow.com/questions/7844399/responsive-image-map http://stackoverflow.com/questions/7943003/dynamically-resizing-image-maps http://stackoverflow.com/questions/12214373/image-mapping-responsive-design http://stackoverflow.com/questions/13321067/dynamically-resizing-image-maps-and-images http://stackoverflow.com/questions/20058971/dynamically-resizing-image-maps-and-images-maphilight-min-js http://stackoverflow.com/questions/23752408/resizing-image-maps-containing-circles http://stackoverflow.com/questions/25806090/how-to-detect-and-change-polygon-shape-co-ordinates-in-image-to-be-responsive http://stackoverflow.com/questions/26298771/how-would-i-create-a-dynamic-hit-zone-that-changes-when-resizing-or-moving-the http://stackoverflow.com/questions/26552283/html-image-map-areas-responsiveness These all appear to want to use variable-size image maps. * Why are alternatives like CSS-positioned a links […] not better? Unlike a elements, areas in an image map can be shaped as a circle or as an author-defined polygon. That's essential when describing parts of certain images. I was going to say that CSS shapes allows other shapes, but apparently it doesn't affect hit testing. * Why are alternatives like […] SVG not better? I didn't know SVG could be used for this. This is new to me, so I'm not sure yet, but it looks quite good. Should the outcome of this discussion be that SVG is good enough to solve all use cases and that image maps are not enhanced, I'd suggest adding a hint to SVGs as a note in the image map section of the HTML spec. Yeah, we could do that in any case. 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
Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior
Ping. Any thoughts from folks familiar with the history API definition?
This proposal resolves a high-profile issue we've received from a number of
major websites. As Majid said, mobile-optimized websites are being forced
to choose between the fullscreen UX users expect from websites on phones
(document scrolling) and the navigation transitions users expect from rich
mobile apps (full page div scrolling). This is unacceptable for apps
trying to provide a 1st-class mobile UX on the web. We're anxious to ship
a solution in blink ASAP.
Thanks,
Rick
On Thu, Mar 19, 2015 at 1:31 PM, Majid Valipour maji...@chromium.org
wrote:
# Problem
Almost all browsers restore scroll position when a user traverses history.
This behavior works well for document style web sites but it is often not
appropriate for single-page web applications where the page content may be
reconstructed (often asynchronously) upon navigation and where the
application
wants to control the details of visual transition between UI states.
Currently it is not possible to disable the scroll behavior so web
developers
have resorted to various hacks [1]. Here are the two most popular:
- Avoid document scrolling altogether by fixing body size and putting
content
in an inner scrollable div. This breaks browser features that depend on
document scrolling such as top controls hiding, or overscroll visuals
and in
some cases disables fast scroll optimizations for document scrolling.
- Use a secondary scroll after browser's initial attempts to restore
scroll.
This leads to two visible jumps and bad UX.
Few documented cases of web developers struggling with this problem may be
found in [2, 3, 4].
# Proposal
Allow web applications to explicitly disable user agents default scroll
restoration behavior via History API. This is achieved by adding a fourth
optional parameter 'options' to both history.pushState,
history.replaceState.
Obviously the default values will be backward compatible. We should also
provide a new attribute (history.options) that exposes the current
effective
value of this new property and use it to provide a simple feature
detection.
Below is the IDL for the proposed changes:
partial interface History {
void pushState(in any data, in DOMString title, in optional DOMString
url, in optional StateOptions options);
void replaceState(in any data, in DOMString title, in optional DOMString
url, in optional StateOptions options);
readonly attribute StateOptions options;
};
dictionary StateOptions {
Boolean restoreScroll = true,
}
Here is a more complete version of this proposal with details around
background, current proposal design, and considered alternative designs:
https://docs.google.com/a/chromium.org/document/d/1Tiu8PjvBtNOAgeh6yrs7bOrXxQcavQLiNtRJ_ToLlVM
We like to implement this or something similar in blink and would be
interested to hear from other vendors. All feedback on proposed design is
welcome. :)
Thanks
Majid Valipour
[1]
http://stackoverflow.com/questions/10742422/prevent-browser-scroll-on-html5-history-popstate
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=679458
[3] https://github.com/rackt/react-router/issues/707
[4] http://andrz.me/blog/scrollx-scroll-why-history
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] HTML6 single-page apps without Javascript proposal now on Github
On Mar 24, 2015, at 9:51 PM, delfin del...@segonquart.net wrote: Hi all: I agree with you all you have quoted, Rendine. * Neal : a problem in developing countries where low end devices are the norm, is _de facto_ THE norme , and was the need of web (standards). * HTML6, if ever, must accomplish and adopt the so called _retro-conditions_, HTML version 5 has. * This conditions are, for example, that one can and must be able to navigate through the Internet pages using an aged and abandoned computer. I mentioned it in the original message with the MREF property, you can use all of this on older browsers. Older browsers will just ignore the MODEL elements and MODEL properties of elements, and will continue to function the same. When you click on a link, instead of fetching the API endpoint that the MREF points to, it uses the canonical URL in the HREF property, like always. This proposal should be backwards compatible on older browsers. If it isn’t, let me know. -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
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
Hi all: I agree with you all you have quoted, Rendine. * Neal : a problem in developing countries where low end devices are the norm, is _de facto_ THE norme , and was the need of web (standards). * HTML6, if ever, must accomplish and adopt the so called _retro-conditions_, HTML version 5 has. * This conditions are, for example, that one can and must be able to navigate through the Internet pages using an aged and abandoned computer. * If this is not the scenario, I highly reccommmend to recover Hypercard, and all that technology that floated round in the mid 90s. * That was not the web build for. * If we cannot collect data , storaged in tags and rendered ( visually, aurally or whatever ) then, I guess we are missing the pòint- * I like the approach Mozunder offers, to avoid unnecesary code , when you can, say, reform the DOM by tags. * Accesibility and the Internet of things. HTML6 must be able to let a talk between machines. * Example: Siri, please, place inside that component a form field including two input tags ( name and password) and a button that says 'Send' Regards On 2015-03-24 13:19, Andrea Rendine 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. 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 [6] 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
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
Hello! By way of introduction, I'm an author who reads some of these mailing lists but (almost) never replies. This proposal is quite interesting, wanted to throw in my two cents as well: 1. Would you consider writing a polyfill/Javascript framework for this? It seems to me that the fundamentals of the proposal could be fairly simply written into a small Javascript polyfill by intercepting a[mref] clicks and filling up templates. A working polyfill would give people a chance to play around with the proposal, give you (and others who like the idea) a working implementation of it in case it doesn't become a standard, and provide an otherwise-necessary polyfill for older browsers if it does become a standard. 2. You've mentioned before that this would be more useful for beginners (who only know HTML, not Javascript), but I don't necessarily agree. With this proposal you would need to explain how the browser downloads JSON data from the mref attribute's location, then somehow parses into a model, and then fills up and displays a template (making what the page is actually showing extremely different from what they write in their editor, not exactly intuitive). IMO the biggest hurdle for a beginner to get over would be conceptually understanding the models and templates, which HTML's declarative nature seems to make more difficult to understand. I would prefer having a Javascript library where the user could write something along the lines of link.onclick = fillTemplate(loadData()), making what's actually happening when a user clicks a link much clearer. The person would still need to understand some Javascript, but not much more than what's necessary for the model attributes in your proposal currently. I'm also curious as to how many beginners would *want* to do a SPA with templates and models like this, I would imagine that by the time you have a real need to load data from a backend API into models and templates without reloading the page that you'd have a workable understanding of Javascript enough to use an existing MVC framework of your choice. Thanks, Matthew Sotoudeh From: mozum...@futureclaw.com Date: Tue, 24 Mar 2015 22:10:12 -0400 To: del...@segonquart.net CC: wha...@whatwg.org; master.skywalker...@gmail.com Subject: Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github On Mar 24, 2015, at 9:51 PM, delfin del...@segonquart.net wrote: Hi all: I agree with you all you have quoted, Rendine. * Neal : a problem in developing countries where low end devices are the norm, is _de facto_ THE norme , and was the need of web (standards). * HTML6, if ever, must accomplish and adopt the so called _retro-conditions_, HTML version 5 has. * This conditions are, for example, that one can and must be able to navigate through the Internet pages using an aged and abandoned computer. I mentioned it in the original message with the MREF property, you can use all of this on older browsers. Older browsers will just ignore the MODEL elements and MODEL properties of elements, and will continue to function the same. When you click on a link, instead of fetching the API endpoint that the MREF points to, it uses the canonical URL in the HREF property, like always. This proposal should be backwards compatible on older browsers. If it isn’t, let me know. -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
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
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] Why CanvasRenderingContext2D uses WebIDL unrestricted float type?
On Tue, Mar 24, 2015 at 1:06 PM, Tetsuharu OHZEKI saneyuki.s...@gmail.com wrote: Hi everybody. I have a question about the definition of CanvasRenderingContext2D's behavior. The current spec about CanvasRenderingContext2D says the following: Except where otherwise specified, for the 2D context interface, any method call with a numeric argument whose value is infinite or a NaN value must be ignored. https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2d But I think that, why don't CanvasRenderingContext2D use restricted float type defined in WebIDL if these methods ignore the value when its is not finite? By the current WebIDL spec (http://heycam.github.io/webidl/#es-double), restricted values, 'float' 'double', will raise TypeError in conversion phase under ECMAScript environment if the passed value is a NaN or +-Infinity. For the purpose to ignore non-restricted values, I feel that it's more better to restrict by IDL type. So the definitions by the current spec is for backward compatibility, or simply a spec issue? We had a long discussion on this about a year ago. In short, we want web APIs to be robust so that if a developer makes a mistakes and passes a NaN or other strange value, the application will attempt to keep on running. Worst case, the app will crash later on anyway and best case, it will show up as a short flicker or not at all.
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
Bobby Mozumder mozum...@futureclaw.com writes: Besides, when was the last time you actually wrote a static HTML file? Does anyone do that? I assume you asked a rhetorical question. Still, the answer is “Yes”. For every web site, people actually write templates, not HTML code. This is provably false. Be careful with “all” quantifiers next time. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] Why CanvasRenderingContext2D uses WebIDL unrestricted float type?
On 3/24/15 4:06 PM, Tetsuharu OHZEKI wrote: But I think that, why don't CanvasRenderingContext2D use restricted float type defined in WebIDL if these methods ignore the value when its is not finite? Because they want to ignore the value. By the current WebIDL spec (http://heycam.github.io/webidl/#es-double), restricted values, 'float' 'double', will raise TypeError in conversion phase under ECMAScript environment if the passed value is a NaN or +-Infinity. Exactly. That's not the same thing as ignoring the value. For the purpose to ignore non-restricted values, I feel that it's more better to restrict by IDL type. Not if you want to actually _ignore_ the value (as opposed to throwing an exception). -Boris
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
On Mar 24, 2015, at 8:07 AM, Neal Gompa ngomp...@gmail.com wrote: 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. I’d like to hear the arguments against it, and in particular, how usability is better without it. I gave several reasons why these frameworks exist in order to fix whats wrong with the web. 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. It’s just an URL syntax that now allows for SQL statements. It’s not the actual connection to a database. If you connect to a remote server, the server can decide to grant you whatever authorization it wishes, through OAuth tokens in the header, through the URL syntax, or whatever. And, for local databases, you can have full control if you want. 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. I never said the client would be consider trusted. Not sure where you got that? Right now, if when you request data via an API endpoint URL, the remote web server transforms that into an SQL query. This proposal lets you request data via an SQL syntax. The remote web server would still need to transform that syntax into an SQL query that’s fit for the server. For example: SELECT first_name, last_name FROM users; would be transformed into: SELECT first_name, last_name FROM users WHERE manager=Boss Man; And this proposal also eliminates the need for a transformative app server when accessing local databases. 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). In the latest version (on the GitHub), I added an MREF property to links to separate the model API endpoint from the canonical URL: A href=“http://www.mywebsite.com/article-2.html; mref=http://api.mywebsite.com/article-2; receiver=“myArticleData When you click on a link, the browser fetches JSON data from http://api.mywebsite.com/article-2;. It then loads that data into “myArticleData, and the URL bar becomes “http://www.mywebsite.com/article-2.html” in the pages domain. The HREF URL is the canonical URL for this piece of data, like always, and this is what people can share and link to from external sites. Does that work? Any problems behind that? -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com twitter.com/futureclaw www.linkedin.com/in/mozumder
Re: [whatwg] HTML6 single-page apps without Javascript proposal now on Github
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 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
[whatwg] Why CanvasRenderingContext2D uses WebIDL unrestricted float type?
Hi everybody. I have a question about the definition of CanvasRenderingContext2D's behavior. The current spec about CanvasRenderingContext2D says the following: Except where otherwise specified, for the 2D context interface, any method call with a numeric argument whose value is infinite or a NaN value must be ignored. https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2d But I think that, why don't CanvasRenderingContext2D use restricted float type defined in WebIDL if these methods ignore the value when its is not finite? By the current WebIDL spec (http://heycam.github.io/webidl/#es-double), restricted values, 'float' 'double', will raise TypeError in conversion phase under ECMAScript environment if the passed value is a NaN or +-Infinity. For the purpose to ignore non-restricted values, I feel that it's more better to restrict by IDL type. So the definitions by the current spec is for backward compatibility, or simply a spec issue? Thanks. -- Tetsuharu OHZEKI
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
