No HTML needed(kojika17.com)
kojika17.com
No HTML needed
http://kojika17.com/demo/4lines/
14 comments
Any chance you were you thinking of http://mathiasbynens.be/notes/css-without-html?
This is http://mathiasbynens.be/notes/css-hidden-elements all over again :)
Here’s an even more extreme version with no HTML at all: http://mathiasbynens.be/notes/css-without-html (read it + try the demo in Firefox)
Here’s an even more extreme version with no HTML at all: http://mathiasbynens.be/notes/css-without-html (read it + try the demo in Firefox)
Page title directly contradicts the HN title: "I drew a camera in HTML and CSS".
What I find interesting is that the <title> attribute is styled and visible in the page, but not technically in the body. I didn't even know that was possible. I'm guessing it's because it's not inside a <head> tag.
Yeah, the first time I saw something like that I was pretty surprised.
You can actually display:block script elements, too. Kinda cool if you need to put a code example on a page and also have that same code actually execute.
You can actually display:block script elements, too. Kinda cool if you need to put a code example on a page and also have that same code actually execute.
Mind blown. That's phenomenally cool. Thanks for the tip.
The browser will still render it inside a <head> tag. Just need to display:block both <head> and <title> (by default display:none I suppose)
Yeah, browser must be assuming everything is body since there is no proper html, head, or body elements. This makes title an unknown tag since it is only defined in the head. Standard for unknown tags is to show the content. Thus why you can put something to show up for someone with no JavaScript in script tags.
The head tag is actually optional (under most conditions) -- supposedly because Netscape patented it. The title shows up because it's set to display:block.
I'd love to see a source on that. <head> is part of the official HTML standard.
The parsing rules in the WHATWG HTML standard (Sec. 12) is one source.
In the "before head" insertion mode (Sec. 12.2.5.4.3) [1] of a compliant HTML parser, encountering a start tag other than for an HTML or HEAD element is defined as inserting a HEAD element and transitioning to the "in head" insertion mode, reprocessing the encountered start tag. So a bare TITLE start tag not enclosed in a HEAD automatically creates an enclosing HEAD element.
I think this actually largely reproduces the behavior of the HTML4 DTD, in which, according to Google [2] the HEAD element is optional.
[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/...
[2] https://developers.google.com/speed/articles/optimizing-html
In the "before head" insertion mode (Sec. 12.2.5.4.3) [1] of a compliant HTML parser, encountering a start tag other than for an HTML or HEAD element is defined as inserting a HEAD element and transitioning to the "in head" insertion mode, reprocessing the encountered start tag. So a bare TITLE start tag not enclosed in a HEAD automatically creates an enclosing HEAD element.
I think this actually largely reproduces the behavior of the HTML4 DTD, in which, according to Google [2] the HEAD element is optional.
[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/...
[2] https://developers.google.com/speed/articles/optimizing-html
I meant a source on Netscape patenting an html tag, not on the fact that it's optional.
Sorry, can't dig up a source. It's the explanation I've heard for IE Classic's handling of head elements.
From a little research, it seems that that explanation is wrong (it sounds like a web dev urban legend dramatizing the "patents mess up everything on the internet" meme). A 1993 draft spec for HTML [1] specifies the ability to include the elements that spec specified as HEAD and BODY elements free floating within the HTML without HEAD and BODY was required of parsers to support "old style documents" using "deprecated" HTML syntax.
This tells us two things: 1) The "support TITLE outside of HEAD" behavior was a necessary to support legacy documents in 1993, before Netscape (as the Mosaic Communications Corporation) was founded in 1994, and 2) The HEAD element itself existed before Netscape was founded in 1994.
This both provides a more likely explanation for the behavior than any Netscape patent and illustrates that it is unlikely that Netscape could have patented the element in any case.
[1] http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
This tells us two things: 1) The "support TITLE outside of HEAD" behavior was a necessary to support legacy documents in 1993, before Netscape (as the Mosaic Communications Corporation) was founded in 1994, and 2) The HEAD element itself existed before Netscape was founded in 1994.
This both provides a more likely explanation for the behavior than any Netscape patent and illustrates that it is unlikely that Netscape could have patented the element in any case.
[1] http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
Thanks for the additional research and of course that makes perfect sense. I shall stop spreading that urban legend.
HTML is primitive. I'll take an internet application any day over a browser. I long for the day when my desktop is filled with application shortcuts, instead of browser shortcuts. I'm already there with android, where developers have learned that more rich, interactive and controlled experience can be had with an application instead of a webpage. I'm sure this burns with HTML developers, but it's only a matter of time before HTML is only a vehicle to direct the user to the app download link.
Funny how most of Android site apps are basically just the website with a different skin and with the annoying-ass "try our app today!" popups on every page removed.
How about Web OS though?
WebOS was by far the best mobile OS available. Unfortunately for all of us, it's just not going to survive. It did so many things right, not only with the UX, but for developers as well. So sad.
Oh god. What awful, awful ideas you have. Where to begin?
Okay, let's start with: How on earth will you ever know what your machine is actually doing?
Do you just run around downloading random .sh and .bat files and say FTW and run them without considering what they might contain? I mean, it's not like the app market actually tells you what an app really does.
All you're ever informed of is those broad, vague categories of behavior an app might engage in. GPS, Camera, Microphone, Intercept phone calls, Storage access... give them all away and run the app. Millions, if not billions of operations frittered away, on your dime, for someone elses benefit.
Sounds like a great idea. Just let everyone hijack your system, and do whatever they want, and don't stop to think about who or why.
...but the EXPERIENCE, man. Just think about the EXPERIENCE!
...or you could just read some words on a page, and look at some pictures, and it stops there. You get to retain a degree of control over your machine. You pretty much know it's only doing a few simple things, and you get to use the rest of your machine for your own purposes, why not?
Okay, let's start with: How on earth will you ever know what your machine is actually doing?
Do you just run around downloading random .sh and .bat files and say FTW and run them without considering what they might contain? I mean, it's not like the app market actually tells you what an app really does.
All you're ever informed of is those broad, vague categories of behavior an app might engage in. GPS, Camera, Microphone, Intercept phone calls, Storage access... give them all away and run the app. Millions, if not billions of operations frittered away, on your dime, for someone elses benefit.
Sounds like a great idea. Just let everyone hijack your system, and do whatever they want, and don't stop to think about who or why.
...but the EXPERIENCE, man. Just think about the EXPERIENCE!
...or you could just read some words on a page, and look at some pictures, and it stops there. You get to retain a degree of control over your machine. You pretty much know it's only doing a few simple things, and you get to use the rest of your machine for your own purposes, why not?
Have you heard of sandboxing? I guess not.
Yes, well, the concept of sandboxing is wonderful, but that's all it is. A concept. An idea. A design pattern. It's not guaranteed to be effective. Many people will go about implementing many different types of sandboxes many different ways.
Yeah, browsers sandbox their active content, and mobile operating systems sandbox their apps, but so what.
Why should everyone acquiesce to being continually haunted by ubiquitous background processes that are constantly monitoring their every zoom, tilt, scroll, highlight and twitch? Why?
Yeah, browsers sandbox their active content, and mobile operating systems sandbox their apps, but so what.
Why should everyone acquiesce to being continually haunted by ubiquitous background processes that are constantly monitoring their every zoom, tilt, scroll, highlight and twitch? Why?
HTML apps do have a major advantage, namely cross platform compatibility and access anywhere - you don't need to install anything, it just runs. I vastly prefer the native app, or even just one that target a managed environment like .net or Java over a "webapp", but the they're not clear-cut better than a native app and for some applications it makes perfect sense.
On the contrary, it's only a matter of time before HTML/CSS/JS reaches the same performance as a native app.
I think we're mostly there already. Firefox OS is, by default, hosting applications written in HTML/JS/CSS.
https://developer.mozilla.org/en/docs/Mozilla/Firefox_OS
https://developer.mozilla.org/en/docs/Mozilla/Firefox_OS
I am of the opposite mindset. I think there are just way too many apps out there and apps lack many things that HTML has - discoverability, cross-platform deploys, reusability and other things. HTML is not for every use case, and native is definitely not the hammer for all use cases. Every time I go to a forum and see the giant display to download a whole app just to see their forum, it makes me throw up a little.
I think the main problem for this decade is that HTML/HTTP aren't realtime (if I worded that correctly) like IRC or something.
HTTP Long Polling, while a little bit of a hack, works incredibly well for most cases. Add in WebSockets and WebRTC in more modern browsers, and you're able to do pretty much any realtime thing you can think of (if you design a server to support it).
The title/header is from HTML. The nicest thing is not the lack of HTML but the lack of an image. The picture is entirely painted by CSS.
Off Topic(sorry): there was a thread here a few months ago about a simple webpage with just html and words. It inspired a whole raft of me-too jokey threads. I'm trying to find it but can't. Does anyone have a link please?
Oh, and here's another hack. Re-interpreting HTML as JS:
http://ajf.me/hacks/js_html/
http://ajf.me/hacks/js_html/
That reminds me of this (from HN a while back):
http://daeken.com/superpacking-js-demos
An html/png hybrid (among other hacks)
http://daeken.com/superpacking-js-demos
An html/png hybrid (among other hacks)
that could be useful for a markupless gui system.
Besides the HTML to include the CSS... Nonetheless, still cool!
Netrenderer shows that IE9 hangs after loading this page... IE10 however seems to work fine.
how did he implement favicon.ico ?
The browser will attempt to retrieve a favicon.ico file from the root of the url.
http://kojika17.com/favicon.ico
http://kojika17.com/favicon.ico
[deleted]
There was a fun demo that showed exactly this, but I can't seem to find it now. This page - http://annevankesteren.nl/test/html-element/style-header.php - uses Link header but also uses some HTML.
[edit - fixed second link]