search

posthtml / sugarml

SugarML Parser
Other
24 stars 1 forks source link

Access #8

Closed michael-ciniawsky closed 7 years ago

michael-ciniawsky commented 7 years ago

@voischev @awinogradov I need access to this repo, make few minor changes and publish a new package then, since the original sugarml npm package is now sadly for reshape.

Name

voischev commented 7 years ago

sml?

michael-ciniawsky commented 7 years ago

index.sml => .smlshould become the default extension for SugarML, like '.sss` is for SugarSS

sml => SugarMarkupLanguage

But maybe posthtml-sugarmlis the better/clearer package name nevertheless...

voischev commented 7 years ago

ok

michael-ciniawsky commented 7 years ago

ok

Ok for posthtml-sml or posthtml-sugarml ? :)

The more I think about posthtml-sugarml the more it makes sense, though no rename would be the best at all.... 😞 . Lesson learned to not give away npm names so easily 👍

michael-ciniawsky commented 7 years ago

do I have access now 👀 ?

jescalan commented 7 years ago

Ended up renaming the extension from sml to sgr because sml is already a language which has been registered on github, can be found by searching google, etc. You guys definitely don't need to make this change, but it might be easiest to do it before the new version is published if you want!

michael-ciniawsky commented 7 years ago

Then posthtml-sugarml is the best option to go forward for now.

Besides that I'm still in favour discussing an eventual merging route between posthtml && reshape in the future

jescalan commented 7 years ago

Happy to discuss this if you want!

voischev commented 7 years ago

do I have access now 👀 ?

yes)

michael-ciniawsky commented 7 years ago

Happy to discuss this if you want!

@jescalan :+1:

@voischev Ok if a make an organisation wide project for that propose? We should have an overall overview of all eventual required/intended changes in all repos :). There is also htmlnano #32 and soon a similiar issue @htmllint to be aware of :). Also a single file component (like Vue Components, but -Vue ;) ) spec + plugin + eventual loader is something I would like to discuss and see whats possible with posthtml.

component.html

<style postcss [critical]></style>

<template id="" name="awesome"></template>

<script babel [critical]></script>

index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title></title>
  <style>Critical CSS from all Components</style>

  <link rel="stylesheet" href="index.css"><!-- CSS from all Components + X-->
</head>
<body>
  <component name="awesome"></component>

  <script>Critical JS from all Components</script>
  <script src="index.js" defer></script><!-- JS from all Components + X -->
</body>
</html>
jescalan commented 7 years ago

So I was also thinking about something like the component thing you posted, but then realized that this is custom element spec + shadow dom, which both already have polyfills that work pretty well, so it got pushed back a decent bit on my list. Might still be a cool experiment though!

I also have an open issue in the vue-loader to open up support for projects like reshape and posthtml, trying to get that pushed through soon.

michael-ciniawsky commented 7 years ago

Yeah this needs definitely futher investigation first, but pretty sure the Single File Component approach, at least in terms of workflow could be made framework agnostic, the web components specs are still in flux, when that finally settles follow the standard and fallback to webcomponents.lite.js polyfill etc.

michael-ciniawsky commented 7 years ago

Done 0ed0d225feposthtml-sugarml v1.0.0-alpha